draft-ietf-ntp-using-nts-for-ntp-13.txt   draft-ietf-ntp-using-nts-for-ntp-14.txt 
NTP Working Group D. Franke NTP Working Group D. Franke
Internet-Draft Internet-Draft Akamai
Intended status: Standards Track D. Sibold Intended status: Standards Track D. Sibold
Expires: March 3, 2019 K. Teichel Expires: April 25, 2019 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
August 30, 2018 October 22, 2018
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-13 draft-ietf-ntp-using-nts-for-ntp-14
Abstract Abstract
This memo specifies Network Time Security (NTS), a mechanism for This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption using Transport Layer Security (TLS) and Authenticated Encryption
with Associated Data (AEAD) to provide cryptographic security for the with Associated Data (AEAD) to provide cryptographic security for the
client-server mode of the Network Time Protocol (NTP). client-server mode of the Network Time Protocol (NTP).
NTS is structured as a suite of two loosely coupled sub-protocols: NTS is structured as a suite of two loosely coupled sub-protocols.
the NTS Key Establishment Protocol (NTS-KE) and NTS Extensions for The first (NTS-KE) handles initial authentication and key
NTPv4. NTS-KE handles NTS service authentication, initial establishment over TLS. The second handles encryption and
handshaking, and key extraction over TLS. Encryption and authentication during NTP time via extension fields in the NTP
authentication during NTP time synchronization is performed through packets, and holds all required state only on the client via opaque
NTS extension fields in otherwise standard NTP packets. Except for cookies.
during the initial NTS-KE process, all state required by the protocol
is held by the client in opaque cookies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 19, line 5 skipping to change at page 19, line 5
of NTS Cookie Placeholder extension fields that the client includes of NTS Cookie Placeholder extension fields that the client includes
SHOULD be such that if the client includes N placeholders and the SHOULD be such that if the client includes N placeholders and the
server sends back N+1 cookies, the number of unused cookies stored by server sends back N+1 cookies, the number of unused cookies stored by
the client will come to eight. The client SHOULD NOT include more the client will come to eight. The client SHOULD NOT include more
than seven NTS Cookie Placeholder extension fields in a request. than seven NTS Cookie Placeholder extension fields in a request.
When both the client and server adhere to all cookie-management When both the client and server adhere to all cookie-management
guidance provided in this memo, the number of placeholder extension guidance provided in this memo, the number of placeholder extension
fields will equal the number of dropped packets since the last fields will equal the number of dropped packets since the last
successful volley. successful volley.
+---------------------------------------+ +---------------------------------------+
| - Verify time request message. | | - Verify time request message |
| - Generate time response message. | | - Generate time response message |
| - Include NTPv4 extension fields: | | - Included NTPv4 extension fields |
| o Unique Identifier EF | | o Unique Identifier EF |
| o NTS Cookie EF | | o NTS Authentication and |
| o <NTS Cookie EF> | | Encrypted Extension Fields EF |
| | | - NTS Cookie EF |
| - Generate AEAD tag of NTP message. | | - <NTS Cookie EF> |
| - Add NTS Authentication and | | - Transmit time request packet |
| Encrypted Extension Fields EF. | +-----------------+---------------------+
| - Transmit time response packet. | |
+-----------------+---------------------+ |
| Server -----------+---------------+-----+----------------------->
| ^ \
Server -----------+---------------+-----+-----------------------> / \
^ \ Time request / \ Time response
/ \ (mode 3) / \ (mode 4)
Time request / \ Time response / \
(mode 3) / \ (mode 4) / V
/ \ Client -----+---------------------------------+---------------->
/ V | |
Client -----+---------------------------------+----------------> | |
| | | |
| | +-----------+----------------------+ +------+-----------------+
| | |- Generate time request message | |- Verify time response |
+-----------+-----------------------+ +-----+------------------+ | - Include NTPv4 Extension fields | | message |
|- Generate time request message. | |- Verify time response | | o Unique Identifier EF | |- Extract cookie(s) |
| - Include NTPv4 extension fields: | | message. | | o NTS Cookie EF | |- Time synchronization |
| o Unique Identifier EF | |- Extract cookie(s). | | o <NTS Cookie Placeholder EF> | | processing |
| o NTS Cookie EF | |- Time synchronization | | | +------------------------+
| o <NTS Cookie Placeholder EF> | | processing. | |- Generate AEAD tag of NTP message|
| | +------------------------+ |- Add NTS Authentication and |
|- Generate AEAD tag of NTP message.| | Encrypted Extension Fields EF |
|- Add NTS Authentication and | |- Transmit time request packet |
| Encrypted Extension Fields EF. | +----------------------------------+
|- Transmit time request packet. |
+-----------------------------------+
Figure 5: NTS Time Synchronization Messages Figure 5: NTS Time Synchronization Messages
The client MAY include additional (non-NTS-related) extension fields The client MAY include additional (non-NTS-related) extension fields
which MAY appear prior to the NTS Authenticator and Encrypted which MAY appear prior to the NTS Authenticator and Encrypted
Extension Fields extension fields (therefore authenticated but not Extension Fields extension fields (therefore authenticated but not
encrypted), within it (therefore encrypted and authenticated), or encrypted), within it (therefore encrypted and authenticated), or
after it (therefore neither encrypted nor authenticated). In after it (therefore neither encrypted nor authenticated). In
general, however, the server MUST discard any unauthenticated general, however, the server MUST discard any unauthenticated
extension fields and process the packet as though they were not extension fields and process the packet as though they were not
skipping to change at page 38, line 8 skipping to change at page 38, line 8
TCP Transmission Control Protocol [RFC0793] TCP Transmission Control Protocol [RFC0793]
TLS Transport Layer Security [RFC8446] TLS Transport Layer Security [RFC8446]
UDP User Datagram Protocol [RFC0768] UDP User Datagram Protocol [RFC0768]
Authors' Addresses Authors' Addresses
Daniel Fox Franke Daniel Fox Franke
Akamai Technologies
150 Broadway
Cambridge, MA 02142
United States
Email: dfoxfranke@gmail.com Email: dafranke@akamai.com
URI: https://www.dfranke.us URI: https://www.dfranke.us
Dieter Sibold Dieter Sibold
Physikalisch-Technische Bundesanstalt Physikalisch-Technische Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Phone: +49-(0)531-592-8420 Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420 Fax: +49-531-592-698420
 End of changes. 9 change blocks. 
52 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/