[Ntp] NTS4UPTP Rev 03 - Update submitted

Heiko Gerstung <heiko.gerstung@meinberg.de> Fri, 04 June 2021 09:42 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 849123A310B for <ntp@ietfa.amsl.com>; Fri, 4 Jun 2021 02:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 XtmOQ9bsaj6H for <ntp@ietfa.amsl.com>; Fri, 4 Jun 2021 02:42:10 -0700 (PDT)
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 0E45F3A30D8 for <ntp@ietf.org>; Fri, 4 Jun 2021 02:42:09 -0700 (PDT)
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 42F9F71C0C54 for <ntp@ietf.org>; Fri, 4 Jun 2021 11:42:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622799727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=kl56IpBVkw8pvs/G2beNSsxQXb3LKcRZ92cxmE/Ul3k=; b=VTgLA5yc1AR/15szSQc4FosZeRNr03z1v1p6TSjAzIf3BSw3PNga7e87ZZ0auvoTDCrZdm 1DxG4LUVP1x8j72VShP2B7by+RC2D3GtFtT6HV0jw63B6cdQK2dz4G4ldbpdg86XtTFPT/ QAanEnkRZgEYSBjVvahe/xw1Tl8NDlcg5VHAZSB4R6lZp4RlRpSvNdVzYe7VtE8wYWUaMS wYEJQjaerYeI+hR46iQwllZD5LFuovlUaXs0U+RVHIoyjlVlDy2D4wd5ptCL1WFHL0xCPQ MlEj22TWLekyqx/2H57uMXnuOhDaUmpoKoYMaXfWCFh8MqZ2yvQ1OlPR5/DV4g==
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 for <ntp@ietf.org>; Fri, 4 Jun 2021 11:42:06 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Fri, 4 Jun 2021 11:42:01 +0200
Message-ID: <8CE53A7F-022C-41F8-92AE-ACBA9BB7A048@meinberg.de>
Thread-Topic: NTS4UPTP Rev 03 - Update submitted
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+ZTBjZDEwODk2MzE3OTFjNA==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: "ntp@ietf.org" <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----3C9460AC6AB291948423F63E6750A49A"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jcAK-DLtkC5gAedWtAHw1CGxQzY>
Subject: [Ntp] NTS4UPTP Rev 03 - Update submitted
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: Fri, 04 Jun 2021 09:42:17 -0000

Hi everyone,

 

I just submitted rev-03 of the draft. It contains the following changes/additions:

 
added a description about the PTP integrated security mechanism in the introduction and explained that PTP assumes that the key management is done outside of PTP and we chose NTS-KE
added a list of objectives resembling the corresponding list in RFC8915, explaining which of the objectives are met and which are not and why
changed the text that unnecessarily talked about not sending a cookie to the client (section 6) and explain how to force the client to refresh its keys when they expired
changed the name of Section (now 8, previously 7) from “Attack Scenarios” to “Threat model”
in this section 8, combined the first bullet and second bullet of the previous revision into one bullet point
added a section 9 describing delay attacks, mention the fact that this document cannot protect against them and give some suggestions what can be done (protect your infrastructure and check delays on the client)
 

 

The draft and its latest revison are here:

https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/

 

The diff can be found here:

https://www.ietf.org/rfcdiff?url1=draft-gerstung-nts4uptp-02&url2=draft-gerstung-nts4uptp-03

 

Looking forward to your comments and feedback! 

 

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

 

 

 

Von: <kristof.teichel@ptb.de>
Datum: Donnerstag, 3. Juni 2021 um 14:23
An: Heiko Gerstung <heiko.gerstung@meinberg.de>
Betreff: Antwort: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption

 

Okay, I've given the draft a closer read now.

Section 2.2 still loses me a bit, as I'm completely unfamiliar with this kind of negotiation, but I think I get the gist of it at least.

 

I have a few concerns about the threat model (Section 7.1):

- General point of order about all bullet points: I tend to ignore the threats that are of the same effectiveness as cutting the wire (client might drop the association, contract might be cancelled...). If you assume a MITM attacker, you won't prevent this overall issue.

- First bullet: yes, this is important, and yes, this is fulfilled to a large degree. The client can verify that the server said everything the ICV covers, and that the message belongs to the correct client-server association. Delay modifications are not really covered (with a small asterisk because of sequence numbers that we keep in mind), and this should perhaps be mentioned.

- Second bullet: very similiar deal to the first bullet - except that it seems to me that the server doesn't even care about this protection.

- Third bullet: Whenever you discuss replay attacks, I kind of miss a consideration about what happens if it's a delay attack instead (which is really a replay attack with an additional deletion of the original message, if you will). It seems dangerous to just ignore this. This is about phase 2, as well, and I'm generally unsure about the implications.

- Fourth bullet: same deal as above - but here I know for a fact that synchronization-wise, delay is about as dangerous (or more) as replay. All of the considerations about "consuming resources" seems a bit pointless, since an attacker would achieve about the same thing with just random messages where the authentication doesn't check out, wouldn't they?

- Fifth bullet: sure. The only comment I might have is that you might want to clarify that this only prevents problems if this authenticated variant is used. But this is a good example of something where replay would actually be harmful whereas delay wouldn't.

 

I'm missing a clear distinction between the one-way transfer aspect of PTP (Announce and Sync messsages) and the part that enables two-way-transfer-like behavior (Delay_Req and Delay_Resp messages).

Section 5, second-to-last paragraph, goes to some lengths to make sure that the server never sends new cookies to the client.

 

a) Is there a specific reason why you did not go for full-on NTS4NTP behavior for Delay_Req/Resp messages?

If this subset of behavior were kept stateless on the server side, I believe this would be a good candidate for the kind of frankensteined construct I was talking about in an earlier mail (do only Delay_Req/Resp exchanges, somehow force the client to timestamp reception of Delay_Resp, and you have all you need - three timestamps is really about as good as four).

This would also allow you to preserve client unlinkability, if I'm not mistaken.

b) Why does the server have an interest to be able to "force the client to re-start"? I might have missed it, but I see no motivation for this in the threat model (and you have no section about your Objectives, which brings me to my last point...)

 

Between Sections 1 and 2, I would really encourage you to add a section about the objectives here.

This would be nice so that they can be compared with NTS4NTP, and also to judge whether or not we actually see that you fulfill them.

 

 

That's what I have for now, I might come back to this later after I've had time to contemplate during a walk or slept over this.

Last point of order: none of these are showstoppers for me, they don't change my stance that I think we can adopt this and discuss further changes/additions that people would like to see.

 

 

Best regards,

Kristof

 

 

-----"ntp" <ntp-bounces@ietf.org> schrieb: -----

An: "kristof.teichel@ptb.de" <kristof.teichel@ptb.de>
Von: "Heiko Gerstung" 
Gesendet von: "ntp" 
Datum: 03.06.2021 12:31
Kopie: "ntp@ietf.org" <ntp@ietf.org>
Betreff: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption


 

> Von: <kristof.teichel@ptb.de>

> Datum: Donnerstag, 3. Juni 2021 um 09:39

> An: Heiko Gerstung <heiko.gerstung@meinberg.de>

> Cc: "ntp@ietf.org" <ntp@ietf.org>

> Betreff: Antwort: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

> 

>>>At this point I would be open to change the name of the draft so that it does

> not contain "NTS" anymore, if that helps. It seems that quite a number of the au

> thors do not like that we based our proposal on their work and would rather like

> unicast PTP to use something else as a key exchange protocol. [...]

> 

> As one of the editors, I do feel misrepresented here.

> There are five of us, only three of whom have spoken about NTS4UPTP at all, with

> only one who spoke out in rejection.

 

Apologies for that, I based that assumption on a feeling and not on factual data (which is never a good thing IMHO but happens quite frequently in real life :).

 

> I will get back to you (after studying the draft in more detail) on what I think

> about how you based your proposal on our work, but I am perfectly happy that yo

> u did.

Glad to hear that. 

 

> @Daniel: would it change your stance if this draft were not named anything with

> "NTS" at all?

 

>>> It is pretty hard to try and compare our proposal against a bunch of ideas th

>>> at are thrown into the discussion. Most of the proposed alternatives seem simple

>>> and easy to describe with two or three sentences, but when we drafted our propo

>>> sal, we found out (once again) that when you try to describe something in writte

>>> n form, a lot of details and corner cases come up that you have to deal with. In

>>> the end, you often end up with at least 10-20 pages, no matter how simple the i

>>> dea sounds in the beginning.

> 

> Yes, absolutely agree.

> And in those pages, you are pretty likely to stumble over the detail that will m

> ake your draft more controversial than you thought.

For sure, but up until now I cannot say that we actually discussed the draft so far.

 

> This is why I want to clarify that (unless I ever explicitly say so) none of my

> technical discussion, wishful thinking or even design sketching is to be taken a

> gainst the NTS4UPTP draft (or other drafts).

OK, thanks. It sometimes gets confusing if those ideas/new concepts are included in a response to a message that deals with the draft. 

 

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

 

 

 

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