Subject: [ntpwg] WG: Re: WGLC on Network Time Security documents (3 documents)

From: [email-masked]
Date: Wed, 9 Mar 2016 13:23:07 +0100

Hi Miroslav,

> On Mon, Mar 07, 2016 at 05:06:10PM +0100, [email-masked] wrote:
> > Hi all,
> > 
> > according to our understanding of the symmetric mode we added the 
> > following language to the draft in order to describe how NTS protects 
the 
> > peer associations.
> 
> Thanks for looking into that. I've few comments. 
> 
> > First: We added section 4.2 "Symmetric (Peer) Modes"
> > 
> >       <section title="Symmetric (Peer) Modes">
> >         <t>For the symmetric modes (active/active, active/passive), 
NTS 
> > works
> >         as it does for the client/server mode, except that both 
> > participants
> >         have to save state information. The participant who first 
sends a 
> > peer
> >         message takes the role of the client, a participant who first 
> > receives
> >         a peer message takes the role of the server, except that it 
keeps
> 
> This is an interesting approach.
> 
> For ephemeral associations I think the server/client direction of the
> NTS association is clear. But for persistent associations, what if
> both peers send packets before receiving reply from the other peer?

This depends heavily on the behavioral policy of an NTS participant who 
has sent request for which are as of yet unanswered.
There is not yet any specification text targeting this.

We are thinking about adding such text, in particular we feel that there 
are at least two obvious approaches: 
1.) "Any sent request starts a process waiting for a response. Any 
incoming message from the intended communication partner which does not 
represent a valid response ends this process and communication must be 
restarted. The process also ends when a valid response is received, or 
when a timeout value is reached."
2.) "Any sent request starts a process waiting for a response. This 
process is only ended either when a valid response is received, or when a 
timeout value is reached." (Implicitly saying that any incoming message is 
treated independently: if it is a request, it is processed as such and 
perhaps answered, if it is a response, it either represents a valid 
response to a pending request, or it is ignored and dropped.)
Currently we feel that the second approach is better for most cases.
In the particular case of peer mode with both peers sending requests 
before receiving replies, it might lead to two associations where only one 
would have been necessary, but this would be a rather benign error.

> What should happen when one of them is restarted, is the NTS
> server/client direction allowed to switch?

Yes, it is. This goes back to what I discussed above.

> 
> >         additional state to strengthen the security guarantees it
> >         receives.</t>
> >       </section>
> 
> An issue I pointed out earlier and that I'd like to see the NTS
> implementation in NTP to address is DoS attack on symmetric
> associations. The NTS association should be able to form and continue
> to work even when an attacker is sending spoofed packets to the peers.

We agree.

> 
> To allow that, I think the peer in the server NTS role shouldn't
> keep or update any state [until...]

We agree. We believe the specification to be consistent with this. If at 
some point it is not, please point this out to us.

> [...] and should respond to all packets from the
> other peer immediately as if they were client mode packets until it
> can save the KIV of the other peer and is ready for time_* messages.

This is tricky. We agree that this would be desirable. However, we think 
that the question of when a response is sent is not regulated by NTS so 
much as it is by the underlying NTP implementation. Since we wish to avoid 
any instances where our specification makes changes to the behavior of 
said underlying implementation, we will probably not add any text about 
this.

> That is also the point when ephemeral associations should be created.

I do not fully understand what your meaning is here. But as far as I can 
grasp it, the answer goes back to the point directly above: this would 
need to be regulated at an NTP level (I believe you would like to prevent 
NTP from creating an ephemeral association before NTS has performed 
authentication/authorization and determined that it will now keep state?).

Best regards,
Kristof
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Mar 2016 16:19:26 +0100

> would have been necessary, but this would be a rather benign error.

Ok, that makes sense, but if the protocol allows and can't prevent two
active peers to accidentaly create two NTS associations instead of
one, why not do that always? The protocol would stay symmetric and the
NTS messages could be restricted by NTP packet mode. I think that
would be a cleaner approach.

> some point it is not, please point this out to us.

The NTP specification requires peers to update their state variables
even if the test of the origin timestamp failed, otherwise the
association couldn't be fully initialized and the peers wouldn't be
able to synchronize to each other. With a symmetric key, that's not a
problem as the authentication always works, there is no initialization
phase and packets with invalid MAC can be always dropped. But with
Autokey or NTS this allows the DoS attack. If we want to prevent it
with NTS, I think the NTS specification will need to modify the
behaviour of NTP peers in the initialization phase.

> authentication/authorization and determined that it will now keep state?).

Yes, exactly.

To summarize my thoughts, I'd suggest the following for symmetric
associations in the NTS-in-NTP spec:

- active peers are always "NTS clients" and may be also "NTS servers"
  if their peer is active too, passive peers are always "NTS servers"
- active packets (mode 1) MUST NOT contain the following NTS messages:
  server_access, server_assoc, server_cook, time_response
- passive packets (mode 2) MUST NOT contain the following NTS messages:
  client_access, client_assoc, client_cook, time_request
- both active and passive peers MUST use passive packet (mode 2) when
  responding to packets with client_access or client_assoc NTS
  messages and they MUST NOT update their NTP state variables (one way
  to do that is to respond immediatelly as if it was a client mode
  packet)
- passive peers mobilize ephemeral associations when the client_cook
  message is accepted

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Wed, 9 Mar 2016 12:53:13 -0500

On 3/9/2016 7:23 AM, [email-masked] wrote:
>> > following language to the draft in order to describe how NTS
> protects the
>> > peer associations.
>>
>> >         <t>For the symmetric modes (active/active, active/passive), NTS
>> > works

If you do this then an attacker can send a spoofed response forcing it
to restart the communication. This sounds like a non-starter.

> process is only ended either when a valid response is received, or when
> a timeout value is reached." (Implicitly saying that any incoming
> message is treated independently: if it is a request, it is processed as
> such and perhaps answered, if it is a response, it either represents a
> valid response to a pending request, or it is ignored and dropped.)
> before receiving replies, it might lead to two associations where only
> one would have been necessary, but this would be a rather benign error.

Danny

---

From: [email-masked]
Date: Fri, 11 Mar 2016 12:48:07 +0100

Hello Miroslav, thanks for your suggestions. See questions below

"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> schrieb am 
09.03.2016 16:19:26:

> Von: Miroslav Lichvar <[email-masked]>
> An: [email-masked]
> Kopie: [email-masked]
> Datum: 09.03.2016 16:54
> Betreff: Re: [ntpwg] WG: Re: WGLC on Network Time Security documents
> (3 documents)
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>
> 

> > before receiving replies, it might lead to two associations where only 
one 

>   if their peer is active too, passive peers are always "NTS servers"

Does this mean that in an active/active association both peers are client 
and server at the same time?

>   messages

Why is this bullet point restricted to client_access and client_assoc? 
What about client_cook and time_request? 

>   and they MUST NOT update their NTP state variables (one way

Shall the peers respond also to time_request messages immediately?

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 11 Mar 2016 13:57:36 +0100

> and server at the same time?

Yes, they both "push" NTS. They save the KIV of the other peer and
compare it with values in received time_request packets. There are no
time_response messages.

To avoid confusion, maybe it would be good to explicitly say that the
direction of the NTP synchronization is not related to the direction
of the NTS server/client association.

> What about client_cook and time_request? 

It actually follows from the first two points, maybe a better wording
would be:
- both active and passive peers use passive packets (mode 2) when
  responding to client_access, client_assoc and client_cook messages
- passive peers respond to time_request with time_response in passive
  packets, active peers never send time_response messages

The second part could then be:
- peers MUST NOT update their NTP state variables when responding to
  the client_access and client_assoc messages

> Shall the peers respond also to time_request messages immediately?

No, I think that should be up to the normal NTP polling process. The
point is that they can update their NTP state variables only from the
client_cook and time_request messages. With the client_cook message
implementations may want to respond immediately as well to not require
additional state, but NTS probably doesn't have to require it.