< draft-ietf-ntp-using-nts-for-ntp-19.txt   draft-ietf-ntp-using-nts-for-ntp-20.txt >
NTP Working Group D. Franke NTP Working Group D. Franke
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track D. Sibold Intended status: Standards Track D. Sibold
Expires: November 1, 2019 K. Teichel Expires: January 9, 2020 K. Teichel
PTB PTB
M. Dansarie M. Dansarie
R. Sundblad R. Sundblad
Netnod Netnod
April 30, 2019 July 8, 2019
Network Time Security for the Network Time Protocol Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-19 draft-ietf-ntp-using-nts-for-ntp-20
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 first (NTS-KE) handles initial authentication and key The first (NTS-KE) handles initial authentication and key
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 November 1, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 18, line 36 skipping to change at page 18, line 36
N: The nonce SHALL be formed however required by the negotiated N: The nonce SHALL be formed however required by the negotiated
AEAD algorithm. AEAD algorithm.
The purpose of the Additional Padding field is to ensure that servers The purpose of the Additional Padding field is to ensure that servers
can always choose a nonce whose length is adequate to ensure its can always choose a nonce whose length is adequate to ensure its
uniqueness, even if the client chooses a shorter one, and still uniqueness, even if the client chooses a shorter one, and still
ensure that the overall length of the server's response packet does ensure that the overall length of the server's response packet does
not exceed the length of the request. For mode 4 (server) packets, not exceed the length of the request. For mode 4 (server) packets,
no Additional Padding field is ever required. For mode 3 (client) no Additional Padding field is ever required. For mode 3 (client)
packets, the length of the Additional Padding field SHALL be computed packets, the length of the Additional Padding field SHALL be computed
as follows. Let `N_LEN` be the padded length of the the Nonce field. as follows. Let `N_LEN` be the padded length of the Nonce field.
Let `N_MAX` be, as specified by RFC 5116 [RFC5116], the maximum Let `N_MAX` be, as specified by RFC 5116 [RFC5116], the maximum
permitted nonce length for the negotiated AEAD algorithm. Let permitted nonce length for the negotiated AEAD algorithm. Let
`N_REQ` be the lesser of 16 and N_MAX, rounded up to the nearest `N_REQ` be the lesser of 16 and N_MAX, rounded up to the nearest
multiple of 4. If N_LEN is greater than or equal to N_REQ, then no multiple of 4. If N_LEN is greater than or equal to N_REQ, then no
Additional Padding field is required. Otherwise, the Additional Additional Padding field is required. Otherwise, the Additional
Padding field SHALL be at least N_REQ - N_LEN octets in length. Padding field SHALL be at least N_REQ - N_LEN octets in length.
Servers MUST enforce this requirement by discarding any packet which Servers MUST enforce this requirement by discarding any packet which
does not conform to it. does not conform to it.
Senders are always free to include more Additional Padding than Senders are always free to include more Additional Padding than
skipping to change at page 22, line 38 skipping to change at page 22, line 38
MUST be valid for use with the NTP server that sent them. They MUST be valid for use with the NTP server that sent them. They
MAY be valid for other NTP servers as well, but there is no way MAY be valid for other NTP servers as well, but there is no way
for the server to indicate this. for the server to indicate this.
We emphasize the contrast that NTS Cookie extension fields MUST NOT We emphasize the contrast that NTS Cookie extension fields MUST NOT
be encrypted when sent from client to server, but MUST be encrypted be encrypted when sent from client to server, but MUST be encrypted
when sent from server to client. The former is necessary in order when sent from server to client. The former is necessary in order
for the server to be able to recover the C2S and S2C keys, while the for the server to be able to recover the C2S and S2C keys, while the
latter is necessary to satisfy the unlinkability goals discussed in latter is necessary to satisfy the unlinkability goals discussed in
Section 10.1. We emphasize also that "encrypted" means encapsulated Section 10.1. We emphasize also that "encrypted" means encapsulated
within the the NTS Authenticator and Encrypted Extensions extension within the NTS Authenticator and Encrypted Extensions extension
field. While the body of an NTS Cookie extension field will field. While the body of an NTS Cookie extension field will
generally consist of some sort of AEAD output (regardless of whether generally consist of some sort of AEAD output (regardless of whether
the recommendations of Section 6 are precisely followed), this is not the recommendations of Section 6 are precisely followed), this is not
sufficient to make the extension field "encrypted". sufficient to make the extension field "encrypted".
The server MAY include additional (non-NTS-related) extension fields The server 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 field (therefore authenticated but not Extension Fields extension field (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
 End of changes. 6 change blocks. 
6 lines changed or deleted 6 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/