Minutes interim-2016-ntp-05: Fri 10:00
minutes-interim-2016-ntp-05-201610141000-02
| Meeting Minutes | Network Time Protocols (ntp) WG | |
|---|---|---|
| Title | Minutes interim-2016-ntp-05: Fri 10:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2016-10-28 |
minutes-interim-2016-ntp-05-201610141000-02
NTP WG Interim Meeting - Boston
Friday October 14, 10:00 am - 5:00 pm
Chairs: Karen O Donoghue and Dieter Sibold
Agenda
======
1. Overview/summary of updates from the core security documents (explanation
of the documents):
draft-ietf-ntp-network-time-security
draft-ietf-ntp-using-nts-for-ntp
draft-dfranke-nts
(no discussion planned, but included here for completeness as part of
the suite of security documents thus far)
draft-ietf-ntp-cms-for-nts-message
Dieter presented a preliminary merged documents of the two drafts
draft-ietf-ntp-using-nts-for-ntp and draft-dfranke-nts (for more details
refer to the session's materials section).
Decisions:
1) What key exchange (KE) protocol to use?
1.a) Do we want to allow optional key exchange mechanisms? (Alternative
KE protocols).
Decision: NO.
1.b) KE for the client server mode (mode 3/mode 4):
Decisions:
- TLS out of band to establish keys. then transmission of
timing information is done with custom protocol from daniel's
draft over UDP/123. - smuggling DTLS KE over NTP extension
fields is tabled for now.
1.c) KE and transport for symmetric peering mode (mode 1/mode 2):
Decision:
TLS (alternatively DTLS) on a port other than UDP/123 to
establish keys, and then timing information is carried over the
TLS record layer.
1.d) KE and transport for control mode (mode 6)
Decision:
DTLS on a port other than UDP/123 to establish keys. then
timing information is carried over the DTLS record layer.
1.e) Open question for mode 1,2,6:
* what port to run the handshake on? 123 or other port?
* what port to run the timing exchange on? 123 or other port?
2) Privacy considerations
- Need to write down the objective in the draft, which seems to
be:
- prevent linkability of client even if the client does
not know that its IP
address has changed from IPa to IPb. We do not want a
*passive* monitor to use info in the NTP/NTS packet to
link IPa and IPb.
- Some justification in the draft for the use case for
which the client does not know that its IP address has
changed.
- Daniel to provide some performance numbers to give us an idea
of the performance of his protocol as currently written in
draft, and also with encryption of the NTP header added.
- Decision: Fix legacy client linkability issues in the NTP
header, because if we don't fix them, all the mechanisms used
to prevent linkability in NTS have little point. Roughly, the
idea is to zero out all identifying fields in the client query
that are not used by the server. Aanchal and Daniel to draft
this.
2. Way forward for the various NTS documents (see above)
- Clarify how Daniel and Kristof can work on the merged documents
- Daniel will provide an update to the merged document according the
decision above mentioned
3. draft-aanchal4-ntp-mac
Aanchal presented an update of the draft-aanchal4-ntp-mac. The new version
of the draft recommends the use of CMAC because of a "nonce reuse
vulnaribility" of a GMAC (for more details refer to the session's materials
section)
4. BCP draft-ietf-ntp-bcp
Denis gave an update of the BCP. It is supposed to be ready for WGLC ...
5. Way forward for drafts related to extension fields and refid
- draft-stenn-ntp-ipv6-refid-hash
- draft-stenn-ntp-leap-smear-refid
- draft-stenn-ntp-not-you-refid
These three drafs shall be combined and resubmitted as
draft-ietf-ntp-refid-updates as possible (Sharon and Harlan)
- draft-mayer-ntp-mac-extension-field
This draft should go forward
- draft-stenn-ntp-last-extension
- draft-stenn-ntp-i-do
The processing on this document has been postponed to later
Jabber archive: https://www.ietf.org/jabber/logs/ntp/2016-10-14.html