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

[[e-mail]]

Hello,

sorry that I'm (perhaps frustratingly) slow to respond.
I'm afraid it is going to stay this way for at least the next two weeks or 
so.

I will have to read the draft closely (focusing on the changes and how 
they adress my comments) later.
This is the majority of issues, but there are a few things that haven't 
gone into the draft and are instead limited to this mail thread.
I'd like to adress these now.

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

I believe this was about amplification.
All I was trying to say was that your approach won't help if the server 
also still responds to unsecured messages.
That's fine in a way, but it feels like it's worth mentioning that you 
only get the benefits if you forgo backwards compatibility (unsure if I'm 
expressing this clearly still).

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

What I meant was that it could have been done in a way that didn't involve 
keeping state on the server side (transmitting the state information on 
request, as in NTS4NTP).

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

What if you were to forgo regular Announce and Sync messages, and instead 
made it so that the server responds to a Delay_Req with a Sync (and 
perhaps Follow_Up) message?
You are already doing unicast, why not go full request-response scheme?
That would actually enable you to just carry most of NTS4NTP's way of 
working over, including the key scheme with the server-side statelessness.
I honestly kind of thought originally that this was going to be what your 
draft did.

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

Yes, I see that it can do that, but why does it want to?
It still seems to me that the draft is deliberately getting rid of a 
mechanism to do on-the-go key refreshing (as NTS4NTP can do with each 
request-response exchange) just so it has a fallback in case someone uses 
an un-fresh key... which would never happen if keys were only used once.
Maybe I'm missing something obvious.


Best regards,
Kristof

P.S.: I can tell you already that I still have a few issues with the new 
draft version, particularly about the goals and how they carry over from 
NTP to PTP in some instances.
But I will go into this once I've given the whole thing another read.





Von:    "Heiko Gerstung" <heiko.gerstung=[e-mail]>
An:     "[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]>
Kopie:  "Doug Arnold" <[e-mail]>
Datum:  08.06.2021 08:34
Betreff:        Re: [Ntp] Antwort: Re: Antwort: Re: NTS4UPTP Rev 03 - 
Formal request for WG adoption
Gesendet von:   "ntp" <[e-mail]>



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: [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: Heiko Gerstung <[e-mail]>
Datum: Donnerstag, 3. Juni 2021 um 16:21
An: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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: [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
 
 
 [Anhang "smime.p7s" gelöscht von Kristof Teichel/PTB] 
_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp