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

Heiko Gerstung <heiko.gerstung@meinberg.de> Mon, 08 March 2021 13:31 UTC

Return-Path: <heiko.gerstung@meinberg.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 CD6CB3A2A0D for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 05:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
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 lOvbuaJM1FVx for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 05:31:10 -0800 (PST)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D2B3A29DA for <ntp@ietf.org>; Mon, 8 Mar 2021 05:31:09 -0800 (PST)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id A1A5F71C0F47; Mon, 8 Mar 2021 14:31:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1615210266; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/XZ8aOM5QUx91X+OHRHKnssqjccSyvQN1mF48YDCjGM=; b=KQnM9lpIJ3ZYdlC6F8BVWc+jJDolMbZxVkDKmhuwxFfA/ubMsDYoMtLnWGHSERLb3LyZmN Q5SCjhG8dhs6Uixk9rcfkiaBUt6n/uJIykydhx0Nfww6tbhvvwxH2m0vj3EcWSHgKOw1Tn hd3r7k9csS9bk2iAeEGSW7GFruocDDbmZceN4IdEU2Pe9rt3DkxCgn5zwST481vNkjHk4e a3bcSWzXXpdDqOKKlVaFbP8yTfgOgzxRWWfXqfD7W6igv6jX6R2OmNLMOj6Y0OUSoxNTKx 88n51TF5+RCWVQk/pmW6HvXTzHBsRzwIrNUhde9eGpfjxpGk7a+eXASeguMF9A==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Mon, 8 Mar 2021 14:31:05 +0100 (CET)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.46.21021202
Date: Mon, 08 Mar 2021 14:31:04 +0100
Message-ID: <792AB323-099C-4A22-B95D-15600EA9CAAC@meinberg.de>
Thread-Topic: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
References: <CACsn0cnz1GfKUKn6q61qmAbs=VPgTGFZnP=kEeQHk9CUxLACXg@mail.gmail.com> <f51dfb1db7c843ecaf58efac526d30ef@ostfalia.de> <6C614D22-A00E-432E-A65E-9A21F8B4476E@meinberg.de> <YEYHHhIrYv4ZhTkl@localhost> <6626A848-B90A-4858-8807-833FD74E6A09@meinberg.de> <YEYhUyx1r6aAO1Xi@localhost>
In-Reply-To: <YEYhUyx1r6aAO1Xi@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NmUxZmZlYTJhY2NhZTU2Mg==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: "Langer, Martin" <mart.langer@ostfalia.de>, Watson Ladd <watsonbladd@gmail.com>, NTP WG <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----D95A6F8FFE844F1A6AC3F82A6EEF3CAC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0tq-0MET2w5OF0XAy4gkMkLJM3s>
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 13:31:13 -0000

Hi Miroslav,

>    If I understand it correctly, the authentication mechanism is already
>    specified in 1588-2019. It just needs some keys to be set up. This
>    draft proposes an NTS-KE based protocol for that.

>From IEEE 1588-2019 Subclause 16.14.1:
"
* Definition of the AUTHENTICATION TLV, allowing for source authentication and message integrity. The AUTHENTICATION TLV carries all necessary information to enable security processing for the sender and the receiver. Note that the AUTHENTICATION TLV has been defined to allow the application of a symmetric key to protect the PTP message. Depending on the associated key management, the AUTHENTICATION TLV supports two different verification approaches: immediate security processing and delayed security processing (see below). The AUTHENTICATION TLV is applicable for both unicast and multicast PTP message transmission.

* Associated key management, which allows for the secure distribution of all necessary security parameters required to construct or verify the AUTHENTICATION TLV. Note that the specific realization of the key management is left open here, as it is a precondition for the AUTHENTICATION TLV. Hence, manual and automated key management may be supported. Annex P provides examples for automated key management including the distribution of keys to be used in group communication for either immediate or delayed security processing."
"
I would assume that the symmetric keys referenced here would be the S2C and C2S keys when using NTS as the key management mechanism. Thus, you are correct that the "PTP integrated security mechansim" of IEEE1588-2019 requires some keys and my proposal would be able to deliver them. 

>    If you don't have any client-specific state on the server (and
>    hardcode the address in the cookie), how do you prevent replay
>    attacks, e.g. canceling a previous request, or changing the message
>    rate to a previous value, or requesting unicast transmissions for
>    clients that no longer exist to cause a DoS attack on the server?

Not sure what you mean with "hardcode the address in the cookie", but in order to change the message rate or cancel a unicast transmission, an NTS4PTP client would have to present a valid cookie. Replay attacks could be prevented by adding an expiration field into the cookie after which a GM will not accept it anymore. 

Regards,
   Heiko



-- 
Heiko Gerstung 
Managing Director 
 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: +49 (0)5281 9309-404 
Fax: +49 (0)5281 9309-9404 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
heiko.gerstung@meinberg.de
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com
 
Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung
 
 

Am 08.03.21, 14:06 schrieb "Miroslav Lichvar" <mlichvar@redhat.com>:

    On Mon, Mar 08, 2021 at 01:41:40PM +0100, Heiko Gerstung wrote:
    > Hi Miroslav,
    > 
    > even if cookies would not be required, I would still want to keep this concept simply because we can re-use the whole NTS4NTP mechanism and do not have to invent yet another protocol etc. 

    If I understand it correctly, the authentication mechanism is already
    specified in 1588-2019. It just needs some keys to be set up. This
    draft proposes an NTS-KE based protocol for that.

    > Plus, you do not need any state for the unicast negotiation itself. It is a short, quick packet exchange between a client and a GM and once it has been completed, the GM does not need to store any data about the client for the next unicast negotiation. When successful, the GM enters the packet transmission phase (which requires state as the GM needs to set up a packet transmission for a slave), but using the cookie concept for the unicast negotiation phase would allow a NTS-KE server to hand out cookies to a NTS/PTP client who could then use them to request packet transmission from a separate list of Unicast GMs. 

    If you don't have any client-specific state on the server (and
    hardcode the address in the cookie), how do you prevent replay
    attacks, e.g. canceling a previous request, or changing the message
    rate to a previous value, or requesting unicast transmissions for
    clients that no longer exist to cause a DoS attack on the server?

    -- 
    Miroslav Lichvar