for-ntp-06 D. Sibold NTPWG Interim Meeting, 14th October 2016, - - PowerPoint PPT Presentation

for ntp 06
SMART_READER_LITE
LIVE PREVIEW

for-ntp-06 D. Sibold NTPWG Interim Meeting, 14th October 2016, - - PowerPoint PPT Presentation

draft-ietf-ntp-using-nts- for-ntp-06 D. Sibold NTPWG Interim Meeting, 14th October 2016, Boston In WG Design Team discussed Items Item Status 1 Mandatory to implemented KE Agreed DTLS - Over separate Port - Piggybacked on NTP header


slide-1
SLIDE 1

draft-ietf-ntp-using-nts- for-ntp-06

  • D. Sibold

NTPWG Interim Meeting, 14th October 2016, Boston

slide-2
SLIDE 2

In WG Design Team discussed Items

Item Status 1 Mandatory to implemented KE Agreed – DTLS

  • Over separate Port
  • Piggybacked on NTP header

2 Are optional KE mechanism allowed? Open 3 Two-way authentication Agreed

  • Second tier effort
  • KE must be able to support mutual

authentication 4 Authorization Agreed

  • Second tier effort

5 Broadcast mode Agreed

  • Second tier effort

However PTP needs broadcast/multicast mode!

2016-10-14

  • D. Sibold, NTP Interim Meeting, Boston

2

slide-3
SLIDE 3

In WG Design Team discussed Items

Item Status 6 Chicken-egg problem Agreed – Discussed in the section “Security considerations” 7 Unauthenticated time packets Agreed – MUST NOT be applied for time synchronization.

  • Discussed in section “Security

considerations” 8 Cryptographic agility Agreement that cryptographic agility is needed A minimum list of mandatory mechanisms shall be provided Message Authentication Code

  • GMAC shall be provided because of

performance advantages

  • HMAC shall be provided especially for

embedded devices 9 Cipher suite selection TBD

  • Daniel proposal already contains language on

2016-10-14

  • D. Sibold, NTP Interim Meeting, Boston

3

slide-4
SLIDE 4

In WG Design Team discussed Items

Item Status 10 Privacy Open

  • New requirement (not included in RFC

7384)

  • Not final agreement

2016-10-14

  • D. Sibold, NTP Interim Meeting, Boston

4

slide-5
SLIDE 5

In WG Design Team discussed Items Summary of open items

Item Notes Are optional KE mechanism allowed? Privacy If yes, is the current approach suffient?

2016-10-14

  • D. Sibold, NTP Interim Meeting, Boston

5

slide-6
SLIDE 6

Daniel’s draft Abstract Introduction DTLS profile for Network Time Security Transport mechanisms for DTLS records The NTS-encapsulated NTPv4 protocol The NTS Key Establishment protocol NTS Extensions for NTPv4 Recommended format for NTS cookies Security Considerations IANA Considerations

Merge of NTS for NTP draft with new proposal

Old draft Abstract Introduction Objectives Terms and Abbreviations Overview of NTS-Secured NTP Protocol Sequence Implementation Notes: ASN.1 Structures and Use

  • f the CMS

IANA Considerations

  • 8. Security Considerations

Preliminary merged draft Abstract Introduction Objectives Terms and Abbreviations Employing DTLS for NTP Security Protocol Sequence for Time Synchronization Messages in Client-Server Mode IANA Considerations

  • 8. Security Considerations

TBD

2016-10-14

  • D. Sibold, NTP Interim Meeting, Boston

6

Contains also language from the generic draft

slide-7
SLIDE 7

Merge of NTS for NTP draft with new proposal

  • TBD
  • Final specification of the protection of time request and

response messages

  • Depends on the privacy requirement
  • Also important for the section “Objectives”
  • Text from Daniel’s introduction
  • Text from Daniel’s essay for the security consideration
  • If optional KE mechanisms are allowed:
  • Current DLTS based KE should exchange key(s) and state

information as application data

  • Broadcast mode has been dismissed

2016-10-14

  • D. Sibold, NTP Interim Meeting, Boston

7