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

From: Watson Ladd <[email-masked]>
Date: Fri, 5 Mar 2021 11:55:22 -0800

Dear WG,

I recognize that this is a pretty early draft and so I'm going to
focus on the aspects that are outlined that I think may be
problematic, rather than nitpick the clear and well written, although
somewhat incomplete text.

My first concern is that this draft doesn't play nicely with NTS. NTS
doesn't have a hierarchical record structure defined, deliberately to
avoid a well-trod class of security and correctness issues. An NTS way
to do this would be to unmake the PTP key grant structure and send a
NTP Next Protocol Negotiation field directly, and use new noncritical
PTP server or group negotiation messages. Obviously it's a bit
complicated by the layering of PTP.

My second concern is cryptographic. Instead of deriving the key from
the TLS handshake, the server sets it. We didn't do this in NTS for
NTP for a reason. The way we do forced key rotations is by getting new
tickets.

Group keys have weaker authentication and security properties than a
tree of unicast associations.

I think this is an important draft that covers a real usecase, but
should try to break the flow of NTS a bit less. I hope these comments
are useful.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: "Langer, Martin" <[email-masked]>
Date: Sun, 7 Mar 2021 17:05:55 +0000

Hello Watson,

first of all thank you very much for the feedback. It is a challenge for me to design
the protocol. NTS4PTP is much more complex than NTS4NTP because the requirements
are very different. Tomorrow there will probably be an update of the draft which will
include the missing chapters. Here once briefly my comments to your feedback:

1) ..."first concern is that this draft doesn't play nicely with NTS"...
The message/communication structure is indeed a problem. While with NTP we only
have a generic request/response to the NTS-KE, with PTP I have to distinguish between
different message types (e.g. unicast/multicast). While with NTS4NTP the communication
between time server and NTS-KE is implementation specific, with NTS4PTP it has to be
defined. This makes it more complex and currently collides with the "NTS Next Protocol
Negotiatin" record. I am open to any suggestions.

2) ..."second concern is cryptographic"...
For keys, we need to distinguish between multicast and unicast. For multicast we use
a group key. This has to be generated, distributed and managed accordingly by the
NTS-KE. A derivation from the TLS session would therefore not be possible, since all
participants need the same key.

With unicast it would be possible, but it makes it more complicated. Theoretically a PTP
client ('requester') can get up to 10 security associations per request, depending on the
PTP profile. The transport of the security parameters to the grantor (e.g. PTP time server)
is done via an encrypted ticket (similar to the cookie in NTP). The cookie solution as with
NTP cannot be applied to PTP, because the message rate is much higher in PTP and the
grantor is stateful. So tracking protection and parameter outsourcing are not needed.
The keys all have a certain lifetime and have to be updated periodically. For NTS4PTP
this is done by the NTS-KE. With NTS4NTP it is done by the time server. But I still see a
problem with NTS4NTP: The MasterKey is rotated, S2C and C2S are not. This contradicts
a bit the key freshness (if I am right).

But here's a question: in what way is it worse to generate a random number (CSPRNG)
instead of deriving it from the TLS connection (TLS Key Exporter)?

3) ..."Group keys have weaker authentication"...
Yes, with a group key we have poor source authentication. To solve this we would need
an approach with asymmetric cryptography (slow) or delayed key disclosure like TESLA
(vulnerable and complex). I don't know of any better alternatives.

... anyway, thank you very much. Tuesday I'm unfortunately not at the IETF meeting due to an exam.

best regards,
Martin

-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: +49 5331 939 43370
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer

________________________________
Von: ntp <[email-masked]> im Auftrag von Watson Ladd <[email-masked]>
Gesendet: Freitag, 5. März 2021 20:55:22
An: NTP WG
Betreff: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Dear WG,

Sincerely,
Watson Ladd

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 8 Mar 2021 11:36:53 +0100

> should try to break the flow of NTS a bit less. I hope these comments

There might be a more general question that needs to be answered
first. What exactly it means for "NTS" to be applied to a time
synchronization protocol? IIRC we originally had a general NTS
draft and a separate NTS-for-NTP draft.

PTP, like the NTP broadcast mode, cannot be secured to the same extent
as the NTP client-server mode. We had some attempts and they failed.

If I understand it correctly, this draft is not trying to apply the
NTS-NTP principles to PTP. That's not possible. It just reuses the
NTS-KE protocol for its own security protocol. I think that's
perfectly fine as long as there is no confusion about the NTS part.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 8 Mar 2021 11:43:29 +0100

Hi WG,

I would agree that we should stay as close as possible to NTS4NTP here. I propose to focus on unicast first, as this is closer to the NTS4NTP use case and “easier” to protect than Multicast communication. 

Securing multicast NTP and PTP is for sure a different beast. As multicast is the prevalent mode of operation for PTP, I would expect that once we found a good solution for PTP in the future, we can adopt this for Multicast NTP as well. And vice versa, since Unicast is the prevalent modus operandi for NTP, we should re-use what has been already developed here for PTP. 

My proposal would be to use exactly the same NTS mechanisms for unicast PTP that we use for NTP, with one addition:

First step is, just like with NTS4NTP, to run the NTS-KE procedure between the NTS/PTP client and the NTS-KE server to allow the client to obtain a number of cookies.
Then, use those cookies when running the unicast message negotiation between the NTS/PTP client and the Unicast PTP grandmaster. 

As far as I can see, up until this point the mechanism can be very similar to NTS4NTP. We most probably need a different cookie format, but the rest should be OK. Once we did 1 + 2, the unicast master will start the PTP packet transmission to the authenticated (via the cookie) PTP client. The client will also start sending Delay Req packets and requires the GM to respond with unicast delay responses. 

During this packet transmission phase I propose to use the S2C to secure the packets from the GM to the client (ANNOUNCE, SYNC, DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP client to the GM (i.e. DELAY_REQ). 

The question is how often we need to change the S2C and C2S keys to avoid that some MITM gets enough time to break the keys before they change. As far as I understood, those keys are part of the cookie and could change in every cookie. That would result in the NTS/PTP client to use a different key after every successful unicast negotiation, something that happens very frequently (and can be configured / chosen by the client). 

This way we could support higher packet rates without any problems as the cookie-secured communication would be limited to the unicast negotiation phase.

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: 

[email-masked]

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: ntp <[email-masked]> im Auftrag von "Langer, Martin" <[email-masked]>
Datum: Sonntag, 7. März 2021 um 18:06
An: Watson Ladd <[email-masked]>, NTP WG <[email-masked]>
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Hello Watson,

best regards,

Martin

-------------------

Martin Langer, M.Eng.

Tel.: +49 5331 939 43370

Dear WG,

Sincerely,
Watson Ladd

_______________________________________________ ntp mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ntp

---

From: "Langer, Martin" <[email-masked]>
Date: Mon, 8 Mar 2021 11:09:49 +0000

Hi all,

orginal text:

--

Miroslav Lichvar

Hello Miroslav,

The generic NTS draft has expired and was not continued.

The multicast connections are not comparable to the broadcast connections in NTP.
In NTP, TESLA-secured communication could be broken, because delay attacks are not
detectable. However, in PTP we have two-way communication (Delay Request/Response)
during multicast, which can be used to register runtime changes (RTT). However, a formal
analysis is indeed not available.

Our NTS4PTP design is still in the early phase. In my opinion, it is already fully functional, but
it could still have various design weaknesses. Of course they have to be eliminated ;)

best regards,

martin

-------------------
Martin Langer, M.Eng.

Tel.: +49 5331 939 43370

________________________________
Von: ntp <[email-masked]> im Auftrag von Miroslav Lichvar <[email-masked]>
Gesendet: Montag, 8. März 2021 11:36
An: Watson Ladd
Cc: NTP WG
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

--
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 8 Mar 2021 12:14:38 +0100

> During this packet transmission phase I propose to use the S2C to secure the packets from the GM to the client (ANNOUNCE, SYNC, DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP cl…

I don't think it makes sense to use NTS cookies in PTP, even if you
limit the NTS support to the unicast mode. The main point of the
cookies is to avoid having client-specific state on the server. That's
not possible in PTP as announce and sync messages are not responses to
requests. They are sent at their own interval, which can be different
from the delay request interval.

In PTP there has to be some client-specific state and the clients need
to be authenticated. Very different from NTS-for-NTP.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 8 Mar 2021 12:38:05 +0100

> The multicast connections are not comparable to the broadcast connections in NTP.

I think they are pretty much the same if you assume the NTP client is
making periodic measurements of the delay and not just once on start.

> analysis is indeed not available.

The delay measurement has a request and response, but the offset
measurement (using sync messages) does not. Delay messages can be much
less frequent than sync messages. That's quite different from the NTP
client-server mode, where each request has an immediate response.

-- 
Miroslav Lichvar

---

From: "Langer, Martin" <[email-masked]>
Date: Mon, 8 Mar 2021 11:44:10 +0000

To a certain extent, an approach would be possible. But we have to look closely at what it means for security.

Cookies would not work directly. If I understand this correctly, then we also don't need 2 keys (C2S, S2C). If I interpret it right, this prevents a security breach if client/server accidentally generate the same nonce in the AEAD operation. With PTP we don't have this (two-way) AEAD operation, but a HMAC/CMAC calculation for the ICV. However, for CMAC I need to check how it behaves there with the initialization vector.  ...it is not quite simple.

Therefore I am always grateful for any feedback and constructive criticism. ;)

-martin-

-------------------
Martin Langer, M.Eng.

Tel.: +49 5331 939 43370

________________________________
Von: Miroslav Lichvar <[email-masked]>
Gesendet: Montag, 8. März 2021 12:38:05
An: Langer, Martin
Cc: NTP WG
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

--
Miroslav Lichvar

---

From: "Langer, Martin" <[email-masked]>
Date: Mon, 8 Mar 2021 11:51:37 +0000

yeah... guess you are right.

In this case we need a periodic unicast connection as a watchdog protocol, ...or something else.

The group-based PTP (multicast) communication is a tricky one.

It is hard to secure. Especially delay attacks.

... on the other hand... it is also a part of the security prongs C and D of PTPv2.1 (redundancy and monitoring).
We are not able to secure packets against delay attacks with cryptographic measures.

-martin-
-------------------
Martin Langer, M.Eng.

Tel.: +49 5331 939 43370

--
Miroslav Lichvar

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 08 Mar 2021 13:12:56 +0100

On 8 Mar 2021, at 12:14, Miroslav Lichvar wrote:

>> As far as I can see, up until this point the mechanism can be very 
>> similar to NTS4NTP. We most probably need a different cookie format, 
>> but the rest should be OK. Once we did 1 + 2, the unicast master will 
>> start the PTP packet transmission to the authenticated (via the 
>> cookie) PTP client. The client will also start sending Delay Req 
>> packets and requires the GM to respond with unicast delay responses.
>>
>> During this packet transmission phase I propose to use the S2C to 
>> secure the packets from the GM to the client (ANNOUNCE, SYNC, 
>> DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP 
>> client to the GM (i.e. DELAY_REQ).
>

I agree with Miroslav. There is already state information defined in the 
IEEE 1588-2019 version in the context of the Authentication TLV. It 
should be possible to use them also for this purpose. This would make 
things easier compared to offload state information via cookies to the 
slaves and would minimize computational for the master.

---

From: "Langer, Martin" <[email-masked]>
Date: Mon, 8 Mar 2021 12:24:51 +0000

Hello everyone,

attached is an intermediate version (draft-langer-ntp-nts-for-ptp-01) as PDF version.
The XML version is not uploaded to the IETF yet. The PDF contains the missing chapters.

many greetings,
Martin

-------------------
Martin Langer, M.Eng.

Tel.: +49 5331 939 43370

________________________________
Von: Dieter Sibold <[email-masked]>
Gesendet: Montag, 8. März 2021 13:12
An: Miroslav Lichvar
Cc: Heiko Gerstung; Watson Ladd; NTP WG; Langer, Martin
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 8 Mar 2021 13:41:40 +0100

Hi Miroslav,

even if cookies would not be required, I would still want to keep this concept simply because we can re-use the whole NTS4NTP mechanism and do not have to invent yet another protocol etc. 

Plus, you do not need any state for the unicast negotiation itself. It is a short, quick packet exchange between a client and a GM and once it has been completed, the GM does not need to store any data about the client for the next unicast negotiation. When successful, the GM enters the packet transmission phase (which requires state as the GM needs to set up a packet transmission for a slave), but using the cookie concept for the unicast negotiation phase would allow a NTS-KE server to hand out cookies to a NTS/PTP client who could then use them to request packet transmission from a separate list of Unicast GMs. 

These Unicast GMs would not need any per-client information from the NTS-KE server instance as they can verify the cookie to make sure this is a valid and authorized NTS client. And then it can use the keys included in the cookie to secure the packet transmission.

If you look at this from  the viewpoint of NTS4NTS, you can basically have an identical phase 1 and phase 2 in NTS4NTP is the actual NTP req/resp exchange whereas in NTS4PTP this is the Unicast Transmission Request and Grant exchange. Up until this point, both can use the same mechanisms. Now, in PTP you have another phase (phase 3) which can have much higher traffic requirements (e.g. 128 pkt/s for one client) and therefore should only use the symmetric C2S and S2C keys. 

My proposal is to keep NTS identical between NTP and PTP for phases 1 and 2 and solve phase 3, e.g. by using the symmetric keys established/exchanged in phase 1.

If we choose to go for a completely different approach, this will most probably slow down adoption and we should really not call it NTS anymore... ;-) 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn: 

Am 08.03.21, 12:15 schrieb "Miroslav Lichvar" <[email-masked]>:

    -- 
    Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 8 Mar 2021 14:06:27 +0100

> even if cookies would not be required, I would still want to keep this concept simply because we can re-use the whole NTS4NTP mechanism and do not have to invent yet another protocol etc. 

If I understand it correctly, the authentication mechanism is already
specified in 1588-2019. It just needs some keys to be set up. This
draft proposes an NTS-KE based protocol for that.

> Plus, you do not need any state for the unicast negotiation itself. It is a short, quick packet exchange between a client and a GM and once it has been completed, the GM does not need to store any…

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?

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 8 Mar 2021 14:31:04 +0100

Hi Miroslav,

>From IEEE 1588-2019 Subclause 16.14.1:
"
* Definition of the AUTHENTICATION TLV, allowing for source authentication and message integrity. The AUTHENTICATION TLV carries all necessary information to enable security processing for the sender and the receiver. Note that the AUTHENTICATION TLV has been defined to allow the application of a symmetric key to protect the PTP message. Depending on the associated key management, the AUTHENTICATION TLV supports two different verification approaches: immediate security processing and delayed security processing (see below). The AUTHENTICATION TLV is applicable for both unicast and multicast PTP message transmission.

* Associated key management, which allows for the secure distribution of all necessary security parameters required to construct or verify the AUTHENTICATION TLV. Note that the specific realization of the key management is left open here, as it is a precondition for the AUTHENTICATION TLV. Hence, manual and automated key management may be supported. Annex P provides examples for automated key management including the distribution of keys to be used in group communication for either immediate or delayed security processing."
"
I would assume that the symmetric keys referenced here would be the S2C and C2S keys when using NTS as the key management mechanism. Thus, you are correct that the "PTP integrated security mechansim" of IEEE1588-2019 requires some keys and my proposal would be able to deliver them. 

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

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn: 

Am 08.03.21, 14:06 schrieb "Miroslav Lichvar" <[email-masked]>:

    -- 
    Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 8 Mar 2021 17:00:01 +0100

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

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 8 Mar 2021 17:23:42 +0100

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 

 
Email: 

Connect via LinkedIn: 

Am 08.03.21, 17:00 schrieb "Miroslav Lichvar" <[email-masked]>:

    -- 
    Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 8 Mar 2021 17:31:45 +0100

>    slaves and would minimize computational for the master.

A PTP unicast master can respond to 128 delay req/s and send 128 sync packets per second to each slave, we are talking quite powerful machines here and I do not think we have to store state information in the cookie. 

A client - just like with NTS4NTP - uses the cookies it gets from the NTS-KE server to authenticate itself vs the unicast GM. The cookies basically provide proof that the client successfully communicated with the NTS-KE and correctly ran phase 1. We would need a little bit of extra state information that needs to be stored on the unicast GM (which already stores state information for every client that successfully requested a unicast transmission). 

My biggest point here is this: yes, it would be possible to design a more lean and more efficient protocol for PTP because PTP already requires some state information being stored on the server. But I believe that this would only save an insignificant number of bytes and CPU cycles on the GM and also on the unicast PTP client. As a benefit, we would get something that is close to how NTS4NTP works, allowing simpler implementation (the NTS-KE part is almost identical and an NTS-KE server would only require some minor modifications to work with unicast PTP clients) and a much faster adoption by the PTP hardware vendors. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: Doug Arnold <[email-masked]>
Date: Mon, 8 Mar 2021 16:38:09 +0000

Most PTP Grandmasters are also NTP servers.  So we should think about how to efficiently implement such time servers, not PTP Grandmasters and NTP servers separately.

Doug

From: ntp <[email-masked]> on behalf of Heiko Gerstung <heiko.gerstung=[email-masked]>
Date: Monday, March 8, 2021 at 11:32 AM
To: Dieter Sibold <[email-masked]>, Miroslav Lichvar <[email-masked]>
Cc: Watson Ladd <[email-masked]>, NTP WG <[email-masked]>, Langer, Martin <[email-masked]>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Regards,
   Heiko

--
Heiko Gerstung
Managing Director

Email:

Connect via LinkedIn:

---

From: "Langer, Martin" <[email-masked]>
Date: Mon, 8 Mar 2021 17:04:56 +0000

Of course, I am also in favor of a solution that is as simple as possible.
Especially since our NTS4PTP design is already quite complex. But we
cannot jeopardize the security.

Whether 'ticket' or 'cookie' is a question of context and requirements. The
term cookie implies state outsourcing for me. And ticket is to me a data
set to get access to a resource. Much more interesting is the question of
what data needs to be exchanged and why.

I am currently under stress and thus I can only respond with some delay.
We should deal with everything objectively and contrast solutions if necessary.
I am thinking if Etherpad would be a possibility to present something like this
in a better way.

-martin-

-------------------
Martin Langer, M.Eng.

Tel.: +49 5331 939 43370

________________________________
Von: Doug Arnold <[email-masked]>
Gesendet: Montag, 8. März 2021 17:38
An: Heiko Gerstung; Dieter Sibold; Miroslav Lichvar
Cc: Watson Ladd; NTP WG; Langer, Martin
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Doug

Regards,
   Heiko

--
Heiko Gerstung
Managing Director

Email:

Connect via LinkedIn:

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 8 Mar 2021 19:11:33 +0100

Martin, 

if the term cookie implies outsourcing state information for you, that’s fine. As I wrote earlier, there is no state information required in the cookie in the proposed approach, just like with NTS4NTP it only contains the keys, a nonce and the algorithm. The state is stored (‚outsourced‘ to) in the unicast GM.

Regards,
Heiko

—
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn: 

> Am 08.03.2021 um 18:05 schrieb Langer, Martin <[email-masked]>:
> 
>