[Ntp] NTS4UPTP Rev 03 - Update submitted

[Heiko Gerstung <[e-mail]>]

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: [phone] 

Fax: [phone] 

 

Amtsgericht Hannover 17HRA 100322 

Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 

 

Email: 

[e-mail]

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: <[e-mail]>
Datum: Donnerstag, 3. Juni 2021 um 14:23
An: Heiko Gerstung <[e-mail]>
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" <[e-mail]> schrieb: -----

An: "[e-mail]" <[e-mail]>
Von: "Heiko Gerstung" 
Gesendet von: "ntp" 
Datum: 03.06.2021 12:31
Kopie: "[e-mail]" <[e-mail]>
Betreff: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption


 

> Von: <[e-mail]>

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

> An: Heiko Gerstung <[e-mail]>

> Cc: "[e-mail]" <[e-mail]>

> 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: [phone] 

Fax: [phone] 

 

Amtsgericht Hannover 17HRA 100322 

Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 

 

Email: 

[e-mail]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp