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

[Heiko Gerstung <[e-mail]>]

Hi Miroslav,

I agree that an expiration date inside the cookie would not help and it would still be an attack vector before it expires.

I would see a chance to avoid replay attacks by using the Sequence Id of the unicast negotiation messages and store this Id in the same space where we store the active subscription datat (i.e. how many packets of which type to which sender for how long) and make sure that I store this "last used sequence id for this client" together with that subscription data. A client then needs to ensure that it always uses a higher sequency id when sending signal messages (e.g. when either canceling a subscription or requesting a new one) in the future. The server would have to store the client/last_seq_id_used/C2S_KEY data even after the subscription got canceled or expired and there was no renewal. For how long this information needs to be stored is probably something to investigate. This is only a problem if a client never comes back and the unicast GM could simply delete all those outdated entries in its database when its master key rotated twice. 

As soon as that client renews its subscription using the same C2S_KEY and a higher sequence Id, the last_seq_id_used will be updated on the server side (together with the updated subscription data). 

If the client crashes and does not know anything about the last_seq_id_used of its former self or in the case it starts for the very first time and there is no last_seq_id_used on the server for it, that should not be a problem because such a client would (re)run NTS-KE and obtain a new C2S_KEY in the process. When it subscribes to the unicast GM afterwards, an existing record will be overwritten because of the new C2S_KEY and the last_seq_id_used will be reset to the seq_id of this new unicast transmission request. If there is no record for this client, one will be created. 

Best 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
 
 

Am 08.03.21, 17:00 schrieb "Miroslav Lichvar" <[e-mail]>:

    On Mon, Mar 08, 2021 at 02:31:04PM +0100, Heiko Gerstung wrote:
    > >    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", 

    That the client's address is included in the cookie to prevent
    replaying from other addresses.

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

    I don't see how could that work.

    How would the server know when will be the cookie used? Even if it had
    only one cookie, it could be used at any time, e.g. to cancel the
    grant when it is shutting down. If it was started soon again, that
    cookie which authenticated the cancelation request would still be
    valid.

    -- 
    Miroslav Lichvar