Skip to main content

Minutes interim-2016-ntp-05: Fri 10:00
minutes-interim-2016-ntp-05-201610141000-01

The information below is for an old version of the document.
Meeting Minutes Network Time Protocols (ntp) WG Snapshot
Date and time 2016-10-14 14:00
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-01
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