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

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 08 June 2021 06:34 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 DC28D3A2439 for <ntp@ietfa.amsl.com>; Mon, 7 Jun 2021 23:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level:
X-Spam-Status: No, score=-2.788 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, RCVD_IN_DNSWL_LOW=-0.7, 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 RLa4u62WoEPE for <ntp@ietfa.amsl.com>; Mon, 7 Jun 2021 23:33:57 -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 6A5273A2435 for <ntp@ietf.org>; Mon, 7 Jun 2021 23:33:56 -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 6AD8E71C0D3E; Tue, 8 Jun 2021 08:33:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=d2021; t=1623134033; 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=YvIKDxEyzBEJLGlTudHbXbQ33fZEldF4YNZHRSmprak=; b=OyWNeyRTqB0dNMgEt0EC7G6TE8Pn09kF/4Fm4C+JRHmlI/7FTqtFfja1Ku5JLpK4c9GrAw ryryE3oYyOC3ULn19jUUv8YWE0efGAlc/xzpAu2ODVylDzo/BY9IdAGjZJTs12wTK9sH/m x5TK2a78eNi+Yg4BnvqG6cyaVD9CWdYD3k/O5oOCXtGtfNAYr8GPX+MphJLjy8t74X8wPI rU7jXwxjZXSC52mZop6zLhWQJcnttovOOa6VYggvKt5wULQMT3cxokNEToZw68PFDEUt/Y 71vA5qZLgChua2KbwLiZZ65fvBpCkBLTCH2H37MJVGrSwFy15g/9C6r0JWsFUQ==
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; Tue, 8 Jun 2021 08:33:52 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Tue, 8 Jun 2021 08:33:50 +0200
Message-ID: <2AB3804B-9B0F-4023-8BEA-7DBC850659C4@meinberg.de>
Thread-Topic: Antwort: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption
References: <A20FC4F4-2626-4060-8DF9-886ADB0E23C8@meinberg.de> <B5F7602A-B084-4B21-9EB2-D25AB030E1EA@meinberg.de> <7F9B8D13-BC90-4E15-9BDF-81714DF0F0C6@meinberg.de> <YLYCLIEA4/unB6/5@localhost> <1DAA3605-CC04-46DE-8CFC-975BED7D4160@meinberg.de> <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost> <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de> <YLZVS4jwGOnMIk6g@localhost> <24DF9BF2-3072-4152-80D6-9F10D53A59AF@meinberg.de> <YLeFyqZp6bZY9nY9@localhost> <OF32A3C2C9.BA5F362B-ONC12586E9.002820A8-C12586E9.002A048D@ptb.de> <OF7A45F954.A8677678-ONC12586E9.00404CC4-C12586E9.0043FF25@ptb.de> <72F69712-8DE7-4FFD-9295-BC8C2C1D58D1@meinberg.de>
In-Reply-To: <72F69712-8DE7-4FFD-9295-BC8C2C1D58D1@meinberg.de>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+YjUxYTMxZGFjYTEzMWE1Mw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: "kristof.teichel@ptb.de" <kristof.teichel@ptb.de>, "ntp@ietf.org" <ntp@ietf.org>
Cc: Doug Arnold <doug.arnold@meinberg-usa.com>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----BCE28326F9B67260BECA5A99FDFF37AA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/2M19BUrjDn9GPuhf0OSb-kv9-5Q>
Subject: Re: [Ntp] Antwort: Re: Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption
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: Tue, 08 Jun 2021 06:34:04 -0000

Hi Kristof,

 

did my response answer your questions? Are there any new questions?

And: did my last submitted revision (-03) address your comments adequately?

 

Thanks a lot for the review so far, looking forward to more comments!

 

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: Heiko Gerstung <heiko.gerstung@meinberg.de>
Datum: Donnerstag, 3. Juni 2021 um 16:21
An: "kristof.teichel@ptb.de" <kristof.teichel@ptb.de>
Cc: "doug.arnold@meinberg-usa.com" <doug.arnold@meinberg-usa.com>
Betreff: Re: 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.

 

OK. We were not sure how much explanation regarding (unicast) PTP we should add to the draft. The main problem with PTP is that it is based on an IEEE standard which is not freely available. Maybe Doug knows a good explanation of the unicast negotiation phase (we have a post in our blog, maybe that helps: https://blog.meinbergglobal.com/2014/04/16/unicast-ptp/).

> 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.

I would say that attacking one service is from a threat perspective equivalent to “cutting the wire”. But I agree that there is nothing you can do if someone owns your switch/router. 

 

> - 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.

I will add a description of delay attacks and explain that this proposal does not offer protection against this kind of attack. I also will add a few sentences explaining how a client can at least defend itself to some degree by setting hard or soft limits for acceptable delay values. 

 

> - 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.

Ultimately you could say that the server does not care about the clients, but the point does not specifically mention that such an attack is negatively affecting the server. It just refers to an attack that is carried out against the server, but it will negatively impact the client. I will try to rephrase it, maybe it is better to just combine the two first bullet points, as they are more or less describing the same thing.

 

> - 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.

I would make the distinction between delay and replay attacks. I would understand a replay attack to be resending a packet that has been received already. In order to carry out a delay attack (or to drop / block packets in general) you need to be able to control the switch/router (MiTM). A replay attack can be carried out by any node that is capable of seeing traffic and sending arbitrary frames. Although from a practical standpoint with unicast communication there are not a lot of potential ways to see other nodes’ traffic without sitting as a MiTM in between sender  and receiver. 

 

> - 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?

I am not sure if this is the same. You can increase the damage if you maximize the number of checks a receiver has to carry out to ultimately find out that it should drop the packet. Regarding the “consuming resources” part: An attacker sending delay requests with invalid ICVs would cause the server to quickly drop the request. That is not as bad as tricking the server into responding (as long as setting up the response and sending it requires more effort than just dropping the invalid request, which I believe is the case here).

 

> - 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.

Not sure if I understood this comment. All the bullet points describe threats/attacks and how the proposed document mitigates them. Can you please explain further?

 

> But this is a good example of something where replay would actually be harmful

> whereas delay wouldn't.

Yes. Although the question with a delay attack is always  to what extend you can delay a packet until a timeout on the receiver results in ignoring it when it finally arrives. Or, in this case, if you delay the request long enough, the client will most probably try to send another request after a timeout. 

 

> 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.

Could be improved to leave out the reference to the cookie that it shall never send, I believe it is good enough to just focus on what it should do (sending random data).

 

> a) Is there a specific reason why you did not go for full-on NTS4NTP behavior

> for Delay_Req/Resp messages?

No sure what you mean with “full-on NTS4NTP behavior”, but I believe there is no gain in adding another layer of security on the delay req/resp exchange in addition to the ICV based protection that is used for all other message types of phase 3. Since this can happen 128 times per second per client, I believe it should be as lean as possible. 

 

> 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).

“Somehow force the client to timestamp reception of Delay Resp” is the key sentence here. The timestamping is done in hardware, which you would have to change to make this work. 

 

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

Yes. Would not be PTP anymore, but using the existing PTP hw timestamping engines out there is definitely possible. You could for example just send a delay request back. 

 

> 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...)

This is related to key freshness. The server can send the client back to the NTS-KE in case the client presents a cookie with an outdated master key. 

 

> 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.

Agreed, let me try to add a section listing the objectives. 

 

> 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.

Thanks a lot, this was exactly the type of comments I was hoping to receive. 

 

> 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.

Great, and thank you for encouraging the other members to express their support or rejection of a possible adoption of the draft by the WG, btw. 

 

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