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

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Mar 2016 12:43:48 +0100

On Tue, Mar 01, 2016 at 06:36:13AM +0000, Karen O'Donoghue wrote:
> This email starts a three week working group last call on the three documents that comprise the Network Time Security effort. Please review and send any comments to the mailing list including your assessment of whether these documents are mature enough to proceed or not. Please send all comments in by Wednesday 23 March 2016. 

It's nice to see the progress that has been made. I'm not familiar
with all details yet, but to me it looks like I could start working on
an implementation of the protocol. I've few questions on some issues
that I think were brought up before, but don't seem to be addressed
yet.

> Using the Network Time Security Specification to Secure the Network Time Protocol
> draft-ietf-ntp-using-nts-for-ntp-04
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Shouldn't there be a description of how NTS works in symmetric
associations? Peering is a major part of the NTP RFC. When I asked
about it before there was some agreement [1] it should start as a
client/server association to obtain the NTS data and switch to the
symmetric mode for the time_request and time_response messages.

Is it expected that NTP packets with extension fields which include
singed data and certificates may exceed the MTU and need IP
fragmentation? Do we need a specification which would allow large
extension fields to be split across several NTP packets?

[1] http://lists.ntp.org/pipermail/ntpwg/2015-September/002344.html

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: [email-masked]
Date: Thu, 3 Mar 2016 08:56:24 +0100

Hi Miroslav,

thank you for the comments and feedback, we appreciate it.
We have put a clarifying section about symmetric mode on the to-do list 
(for the NTS-4-NTP document).

Best regards,
Kristof

"ntpwg" <ntpwg-bounces+kristof.teichel=[email-masked]> schrieb am 
01.03.2016 12:43:48:

> Von: Miroslav Lichvar <[email-masked]>
> An: [email-masked]
> Datum: 01.03.2016 13:36
> Betreff: Re: [ntpwg] WGLC on Network Time Security documents (3 
documents)
> Gesendet von: "ntpwg" 
<ntpwg-bounces+kristof.teichel=[email-masked]>
> > This email starts a three week working group last call on the 
> three documents that comprise the Network Time Security effort. 
> Please review and send any comments to the mailing list including 
> your assessment of whether these documents are mature enough to 
> proceed or not. Please send all comments in by Wednesday 23 March 2016. 
>

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 03 Mar 2016 18:02:57 +0000

Miroslav Lichvar writes:
>> Using the Network Time Security Specification to Secure the Network
>> Time Protocol draft-ietf-ntp-using-nts-for-ntp-04
> associations? Peering is a major part of the NTP RFC. ...

We discussed this issue in our NTS implementation call today.

We're pretty comfortable saying the following:

An established NTS association WILL have enough information to
authenticate/authorize one side as a server and the other side as a
client.  This allows either client/server associations or active/passive
peer associations.

An established NTS association MAY have enough information to
authenticate/authorize both sides as servers.  This allows
client/server, active/passive peer, or active/active peer associations.

The draft will be augmented to better describe this situation.

> signed data and certificates may exceed the MTU and need IP

We did not discuss this issue in the call.  I believe we're currently
letting IP fragmentation handle this.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: [email-masked]
Date: Fri, 4 Mar 2016 12:08:50 +0100

> letting IP fragmentation handle this.

While we left it out in yesterday's call, Dieter and I discussed this with 
Martin Langer (our student implementer for NTS-protected NTP). We arrived 
at the following conclusions:

1) None of the NTS-related content is predicted to cause an issue with the 
64 KB limit for extension fields / UDP datagrams. 
NTS should therefore never make it necessary to split messages into 
multiple NTP packets.

2) Our quick research concluded MTU limits to be usually between 576 and 
1500 bytes.
Only those NTS exchanges which include certificate chains or signatures 
are foreseen to exceed those limits. 
In particular, the protected time synchronization messages are under MTU 
limits. 
For those messages which do exceed MTU limits, IP fragmentation did not 
seem like a significant detriment to us.

I am attaching a tabular overview of estimated message sizes for the NTP 
packets carrying different NTS messages (I translated it from data 
supplied by Martin).

@Richard: can you make a statement about whether these estimations match 
what you expect for your implementation?

@All: Overall feedback? Are there ideas as to how IP fragmentation could 
cause problems that we did not consider?

Best regards,
Kristof

---

From: [email-masked]
Date: Mon, 7 Mar 2016 17:06:10 +0100

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.

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
        additional state to strengthen the security guarantees it
        receives.</t>
      </section>

Second: We changed respectively added language to  the section 5.2.1 "The 
Server in Unicast Mode". 

              <t>Upon receipt of a client_cook message, the server checks
              whether it supports the given cryptographic algorithms. The
              server MAY use the client's certificate to authenticate the
              client and to check that it is authorized to use the secure 
time
              synchronization service. <list style="symbols">
                  <t>In the case where a client_cook message was received 
in
                  the context of an NTP peer (mode 1) association, the
                  aforementioned authentication and authorization checks 
MUST
                  be performed. If these checks are successfull, the 
server
                  MUST memorize the hash value of the client's
                  certificate.</t>
                </list>After successfully performing the checks, the 
server
              MUST calculate the cookie and then construct a server_cook
              message as described in <xref
              target="I-D.ietf-ntp-network-time-security"/>.</t>

             <t>Upon receipt of a time_request message, the server
              re-calculates the cookie and the MAC for that time_request
              packet and compares this value with the MAC in the received
              data. <list style="symbols">
                  <t>If the re-calculated MAC does not match the MAC in 
the
                  received data the server MUST stop the processing of the
                  request.</t>

                  <t>If the re-calculated MAC matches the MAC in the 
received
                  data the server computes the necessary time 
synchronization
                  data and constructs a time_response message as given in
                  <xref target="I-D.ietf-ntp-network-time-security"/>.</t>
                </list>If the time_request message was received in the 
context
              of an NTP peer (mode 1) association, the server MUST check 
that
              it has memorized the given hash value of the client's
              certificate. If it has not, it MUST NOT use the NTP message
              contents for adjusting its own clock.</t>
            </list></t>

Any comments?

-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT
Bundesallee 100 
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: [email-masked]

"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> schrieb am 
03.03.2016 19:02:57:

> Von: Harlan Stenn <[email-masked]>
> An: Miroslav Lichvar <[email-masked]>
> Kopie: [email-masked]
> Datum: 03.03.2016 19:46
documents)
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>
> 
> Miroslav Lichvar writes:

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 8 Mar 2016 12:05:09 +0100

> following language to the draft in order to describe how NTS protects the 

Thanks for looking into that. I've few comments. 

>         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?
What should happen when one of them is restarted, is the NTS
server/client direction allowed to switch?

>         additional state to strengthen the security guarantees it

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.

To allow that, I think the peer in the server NTS role shouldn't
keep or update any state 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.
That is also the point when ephemeral associations should be created.

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 11 Mar 2016 11:02:46 +0100

> cause problems that we did not consider?

My concern is that if NTS requires fragmentation even with the
ethernet MTU (1500), it will be a problem for a lot of users. Is there
any widely used protocol that needs IP fragmentation with MTU of 1500? 

My understanding (which may be completely wrong) is that it's not
uncommon for firewalls to drop ICMP packets or IP fragments. Also, in
IPv6 it seems hosts are not even required to defragment packets larger
than 1500. Wouldn't that be a problem?

On an unrelated note, I noticed in the table with expected NTS message
sizes that time_request is different from time_response. Would it make
sense to pad time_response to keep the time needed for HMAC
calculation and transmission/reception of the packet symmetric to not
add an extra offset to the measurements (assuming same HW on both
ends)?

Do the time_* messages actually include the NTS version? The
cms-for-ntp draft doesn't seem to include that field, but the ntp-nts
draft does. Also, I'm wondering if it's really necessary to include
the nonce in the time_* messages (shouldn't be the origin timestamp
enough?) and if NTP packets with the most common NTS messages couldn't
be shorter.