| < draft-ietf-ntp-using-nts-for-ntp-27.txt | draft-ietf-ntp-using-nts-for-ntp-28.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: September 25, 2020 K. Teichel | Expires: September 26, 2020 K. Teichel | |||
| PTB | PTB | |||
| M. Dansarie | M. Dansarie | |||
| R. Sundblad | R. Sundblad | |||
| Netnod | Netnod | |||
| March 24, 2020 | March 25, 2020 | |||
| Network Time Security for the Network Time Protocol | Network Time Security for the Network Time Protocol | |||
| draft-ietf-ntp-using-nts-for-ntp-27 | draft-ietf-ntp-using-nts-for-ntp-28 | |||
| 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 September 25, 2020. | This Internet-Draft will expire on September 26, 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 6, line 16 ¶ | skipping to change at page 6, line 16 ¶ | |||
| establishing key material for use with the NTS Extension Fields | establishing key material for use with the NTS Extension Fields | |||
| for NTPv4. It uses TLS to establish keys, provide the client with | for NTPv4. It uses TLS to establish keys, provide the client with | |||
| an initial supply of cookies, and negotiate some additional | an initial supply of cookies, and negotiate some additional | |||
| protocol options. After this, the TLS channel is closed with no | protocol options. After this, the TLS channel is closed with no | |||
| per-client state remaining on the server side. | per-client state remaining on the server side. | |||
| The typical protocol flow is as follows: The client connects to an | The typical protocol flow is as follows: The client connects to an | |||
| NTS-KE server on the NTS TCP port and the two parties perform a TLS | NTS-KE server on the NTS TCP port and the two parties perform a TLS | |||
| handshake. Via the TLS channel, the parties negotiate some | handshake. Via the TLS channel, the parties negotiate some | |||
| additional protocol parameters and the server sends the client a | additional protocol parameters and the server sends the client a | |||
| supply of cookies along with an address of an NTP server for which | supply of cookies along with an address and port of an NTP server for | |||
| the cookies are valid. The parties use TLS key export [RFC5705] to | which the cookies are valid. The parties use TLS key export | |||
| extract key material which will be used in the next phase of the | [RFC5705] to extract key material which will be used in the next | |||
| protocol. This negotiation takes only a single round trip, after | phase of the protocol. This negotiation takes only a single round | |||
| which the server closes the connection and discards all associated | trip, after which the server closes the connection and discards all | |||
| state. At this point the NTS-KE phase of the protocol is complete. | associated state. At this point the NTS-KE phase of the protocol is | |||
| Ideally, the client never needs to connect to the NTS-KE server | complete. Ideally, the client never needs to connect to the NTS-KE | |||
| again. | server again. | |||
| Time synchronization proceeds with the indicated NTP server over the | Time synchronization proceeds with the indicated NTP server. The | |||
| NTP UDP port. The client sends the server an NTP client packet which | client sends the server an NTP client packet which includes several | |||
| includes several extension fields. Included among these fields are a | extension fields. Included among these fields are a cookie | |||
| cookie (previously provided by the key establishment server) and an | (previously provided by the key establishment server) and an | |||
| authentication tag, computed using key material extracted from the | authentication tag, computed using key material extracted from the | |||
| NTS-KE handshake. The NTP server uses the cookie to recover this key | NTS-KE handshake. The NTP server uses the cookie to recover this key | |||
| material and send back an authenticated response. The response | material and send back an authenticated response. The response | |||
| includes a fresh, encrypted cookie which the client then sends back | includes a fresh, encrypted cookie which the client then sends back | |||
| in the clear in a subsequent request. (This constant refreshing of | in the clear in a subsequent request. (This constant refreshing of | |||
| cookies is necessary in order to achieve NTS's unlinkability goal.) | cookies is necessary in order to achieve NTS's unlinkability goal.) | |||
| Figure 1 provides an overview of the high-level interaction between | Figure 1 provides an overview of the high-level interaction between | |||
| the client, the NTS-KE server, and the NTP server. Note that the | the client, the NTS-KE server, and the NTP server. Note that the | |||
| cookies' data format and the exchange of secrets between NTS-KE and | cookies' data format and the exchange of secrets between NTS-KE and | |||
| skipping to change at page 10, line 16 ¶ | skipping to change at page 10, line 16 ¶ | |||
| displays the protocol steps to be performed by the NTS client and | displays the protocol steps to be performed by the NTS client and | |||
| server and record types to be exchanged. | server and record types to be exchanged. | |||
| +---------------------------------------+ | +---------------------------------------+ | |||
| | - Verify client request message. | | | - Verify client request message. | | |||
| | - Extract TLS key material. | | | - Extract TLS key material. | | |||
| | - Generate KE response message. | | | - Generate KE response message. | | |||
| | - Include Record Types: | | | - Include Record Types: | | |||
| | o NTS Next Protocol Negotiation | | | o NTS Next Protocol Negotiation | | |||
| | o AEAD Algorithm Negotiation | | | o AEAD Algorithm Negotiation | | |||
| | o NTP Server Negotiation | | | o <NTPv4 Server Negotiation> | | |||
| | o <NTPv4 Port Negotiation> | | ||||
| | o New Cookie for NTPv4 | | | o New Cookie for NTPv4 | | |||
| | o <New Cookie for NTPv4> | | | o <New Cookie for NTPv4> | | |||
| | o End of Message | | | o End of Message | | |||
| +-----------------+---------------------+ | +-----------------+---------------------+ | |||
| | | | | |||
| | | | | |||
| Server -----------+---------------+-----+-----------------------> | Server -----------+---------------+-----+-----------------------> | |||
| ^ \ | ^ \ | |||
| / \ | / \ | |||
| / TLS application \ | / TLS application \ | |||
| skipping to change at page 10, line 38 ¶ | skipping to change at page 10, line 39 ¶ | |||
| / \ | / \ | |||
| / V | / V | |||
| Client -----+---------------------------------+-----------------> | Client -----+---------------------------------+-----------------> | |||
| | | | | | | |||
| | | | | | | |||
| | | | | | | |||
| +-----------+----------------------+ +------+-----------------+ | +-----------+----------------------+ +------+-----------------+ | |||
| |- Generate KE request message. | |- Verify server response| | |- Generate KE request message. | |- Verify server response| | |||
| | - Include Record Types: | | message. | | | - Include Record Types: | | message. | | |||
| | o NTS Next Protocol Negotiation | |- Extract cookie(s). | | | o NTS Next Protocol Negotiation | |- Extract cookie(s). | | |||
| | o AEAD Algorithm Negotiation | | | | | o AEAD Algorithm Negotiation | +------------------------+ | |||
| | o <NTP Server Negotiation> | | | | | o <NTPv4 Server Negotiation> | | |||
| | o End of Message | | | | | o <NTPv4 Port Negotiation> | | |||
| +----------------------------------+ +------------------------+ | | o End of Message | | |||
| +----------------------------------+ | ||||
| Figure 3: NTS Key Establishment Messages | Figure 3: NTS Key Establishment Messages | |||
| 4.1. NTS-KE Record Types | 4.1. NTS-KE Record Types | |||
| The following NTS-KE Record Types are defined: | The following NTS-KE Record Types are defined: | |||
| 4.1.1. End of Message | 4.1.1. End of Message | |||
| The End of Message record has a Record Type number of 0 and a zero- | The End of Message record has a Record Type number of 0 and a zero- | |||
| skipping to change at page 13, line 30 ¶ | skipping to change at page 13, line 30 ¶ | |||
| 4.1.7. NTPv4 Server Negotiation | 4.1.7. NTPv4 Server Negotiation | |||
| The NTPv4 Server Negotiation record has a Record Type number of 6. | The NTPv4 Server Negotiation record has a Record Type number of 6. | |||
| Its body consists of an ASCII-encoded [RFC0020] string. The contents | Its body consists of an ASCII-encoded [RFC0020] string. The contents | |||
| of the string SHALL be either an IPv4 address, an IPv6 address, or a | of the string SHALL be either an IPv4 address, an IPv6 address, or a | |||
| fully qualified domain name (FQDN). IPv4 addresses MUST be in dotted | fully qualified domain name (FQDN). IPv4 addresses MUST be in dotted | |||
| decimal notation. IPv6 addresses MUST conform to the "Text | decimal notation. IPv6 addresses MUST conform to the "Text | |||
| Representation of Addresses" as specified in RFC 4291 [RFC4291] and | Representation of Addresses" as specified in RFC 4291 [RFC4291] and | |||
| MUST NOT include zone identifiers [RFC6874]. If a label contains at | MUST NOT include zone identifiers [RFC6874]. If a label contains at | |||
| least one non-ASCII character, it is an internationalized domain name | least one non-ASCII character, it is an internationalized domain name | |||
| and an A-LABEL MUST be used as defined in section 2.3.2.1 of RFC 5890 | and an A-LABEL MUST be used as defined in Section 2.3.2.1 of RFC 5890 | |||
| [RFC5890]. If the record contains a domain name, the recipient MUST | [RFC5890]. If the record contains a domain name, the recipient MUST | |||
| treat it as a FQDN, e.g. by making sure it ends with a dot. | treat it as a FQDN, e.g. by making sure it ends with a dot. | |||
| When NTPv4 is negotiated as a Next Protocol and this record is sent | When NTPv4 is negotiated as a Next Protocol and this record is sent | |||
| by the server, the body specifies the hostname or IP address of the | by the server, the body specifies the hostname or IP address of the | |||
| NTPv4 server with which the client should associate and which will | NTPv4 server with which the client should associate and which will | |||
| accept the supplied cookies. If no record of this type is sent, the | accept the supplied cookies. If no record of this type is sent, the | |||
| client SHALL interpret this as a directive to associate with an NTPv4 | client SHALL interpret this as a directive to associate with an NTPv4 | |||
| server at the same IP address as the NTS-KE server. Servers MUST NOT | server at the same IP address as the NTS-KE server. Servers MUST NOT | |||
| send more than one record of this type. | send more than one record of this type. | |||
| skipping to change at page 14, line 45 ¶ | skipping to change at page 14, line 45 ¶ | |||
| A mechanism for not unnecessarily overloading the NTS-KE server is | A mechanism for not unnecessarily overloading the NTS-KE server is | |||
| REQUIRED when retrying the key establishment process due to protocol, | REQUIRED when retrying the key establishment process due to protocol, | |||
| communication, or other errors. The exact workings of this will be | communication, or other errors. The exact workings of this will be | |||
| dependent on the application and operational experience gathered over | dependent on the application and operational experience gathered over | |||
| time. Until such experience is available, this memo provides the | time. Until such experience is available, this memo provides the | |||
| following suggestion. | following suggestion. | |||
| Clients SHOULD use exponential backoff, with an initial and minimum | Clients SHOULD use exponential backoff, with an initial and minimum | |||
| retry interval of 10 seconds, a maximum retry interval of 5 days, and | retry interval of 10 seconds, a maximum retry interval of 5 days, and | |||
| a base of 1.5. Thus, the minimum interval in seconds, t, for the nth | a base of 1.5. Thus, the minimum interval in seconds, `t`, for the | |||
| retry is calculated with | nth retry is calculated with | |||
| t = min(10 * 1.5^(n-1), 432000). | t = min(10 * 1.5^(n-1), 432000). | |||
| Clients MUST NOT reset the retry interval until they have performed a | Clients MUST NOT reset the retry interval until they have performed a | |||
| successful key establishment with the NTS-KE server, followed by a | successful key establishment with the NTS-KE server, followed by a | |||
| successful use of the negotiated next protocol with the keys and data | successful use of the negotiated next protocol with the keys and data | |||
| established during that transaction. | established during that transaction. | |||
| 4.3. Key Extraction (generally) | 4.3. Key Extraction (generally) | |||
| skipping to change at page 15, line 20 ¶ | skipping to change at page 15, line 20 ¶ | |||
| be extracted using the HMAC-based Extract-and-Expand Key Derivation | be extracted using the HMAC-based Extract-and-Expand Key Derivation | |||
| Function (HKDF) [RFC5869] in accordance with RFC 8446, Section 7.5 | Function (HKDF) [RFC5869] in accordance with RFC 8446, Section 7.5 | |||
| [RFC8446]. Inputs to the exporter function are to be constructed in | [RFC8446]. Inputs to the exporter function are to be constructed in | |||
| a manner specific to the negotiated Next Protocol. However, all | a manner specific to the negotiated Next Protocol. However, all | |||
| protocols which utilize NTS-KE MUST conform to the following two | protocols which utilize NTS-KE MUST conform to the following two | |||
| rules: | rules: | |||
| The disambiguating label string [RFC5705] MUST be "EXPORTER- | The disambiguating label string [RFC5705] MUST be "EXPORTER- | |||
| network-time-security". | network-time-security". | |||
| The per-association context value MUST be provided and MUST begin | The per-association context value [RFC5705] MUST be provided and | |||
| with the two-octet Protocol ID which was negotiated as a Next | MUST begin with the two-octet Protocol ID which was negotiated as | |||
| Protocol. | a Next Protocol. | |||
| 5. NTS Extension Fields for NTPv4 | 5. NTS Extension Fields for NTPv4 | |||
| 5.1. Key Extraction (for NTPv4) | 5.1. Key Extraction (for NTPv4) | |||
| Following a successful run of the NTS-KE protocol wherein Protocol ID | Following a successful run of the NTS-KE protocol wherein Protocol ID | |||
| 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be | 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be | |||
| extracted: a client-to-server (C2S) key and a server-to-client (S2C) | extracted: a client-to-server (C2S) key and a server-to-client (S2C) | |||
| key. These keys SHALL be computed with the HKDF defined in RFC 8446, | key. These keys SHALL be computed with the HKDF defined in RFC 8446, | |||
| Section 7.5 [RFC8446] using the following inputs. | Section 7.5 [RFC8446] using the following inputs. | |||
| The disambiguating label string [RFC5705] SHALL be "EXPORTER- | The disambiguating label string [RFC5705] SHALL be "EXPORTER- | |||
| network-time-security". | network-time-security". | |||
| The context value SHALL consist of the following five octets: | The per-association context value [RFC5705] SHALL consist of the | |||
| following five octets: | ||||
| The first two octets SHALL be zero (the Protocol ID for NTPv4). | The first two octets SHALL be zero (the Protocol ID for NTPv4). | |||
| The next two octets SHALL be the Numeric Identifier of the | The next two octets SHALL be the Numeric Identifier of the | |||
| negotiated AEAD Algorithm in network byte order. | negotiated AEAD Algorithm in network byte order. | |||
| The final octet SHALL be 0x00 for the C2S key and 0x01 for the | The final octet SHALL be 0x00 for the C2S key and 0x01 for the | |||
| S2C key. | S2C key. | |||
| Implementations wishing to derive additional keys for private or | Implementations wishing to derive additional keys for private or | |||
| skipping to change at page 16, line 39 ¶ | skipping to change at page 16, line 39 ¶ | |||
| storage of session state onto the client. The purpose of the unique | storage of session state onto the client. The purpose of the unique | |||
| identifier extension field is to protect the client from replay | identifier extension field is to protect the client from replay | |||
| attacks. | attacks. | |||
| 5.3. The Unique Identifier Extension Field | 5.3. The Unique Identifier Extension Field | |||
| The Unique Identifier extension field provides the client with a | The Unique Identifier extension field provides the client with a | |||
| cryptographically strong means of detecting replayed packets. It has | cryptographically strong means of detecting replayed packets. It has | |||
| a Field Type of [[TBD2]]. When the extension field is included in a | a Field Type of [[TBD2]]. When the extension field is included in a | |||
| client packet (mode 3), its body SHALL consist of a string of octets | client packet (mode 3), its body SHALL consist of a string of octets | |||
| generated uniformly at random. The string MUST be at least 32 octets | generated by a cryptographically secure random number generator | |||
| long. When the extension field is included in a server packet (mode | [RFC4086]. The string MUST be at least 32 octets long. When the | |||
| 4), its body SHALL contain the same octet string as was provided in | extension field is included in a server packet (mode 4), its body | |||
| the client packet to which the server is responding. All server | SHALL contain the same octet string as was provided in the client | |||
| packets generated by NTS-implementing servers in response to client | packet to which the server is responding. All server packets | |||
| packets containing this extension field MUST also contain this field | generated by NTS-implementing servers in response to client packets | |||
| with the same content as in the client's request. The field's use in | containing this extension field MUST also contain this field with the | |||
| modes other than client-server is not defined. | same content as in the client's request. The field's use in modes | |||
| other than client-server is not defined. | ||||
| This extension field MAY also be used standalone, without NTS, in | This extension field MAY also be used standalone, without NTS, in | |||
| which case it provides the client with a means of detecting spoofed | which case it provides the client with a means of detecting spoofed | |||
| packets from off-path attackers. Historically, NTP's origin | packets from off-path attackers. Historically, NTP's origin | |||
| timestamp field has played both these roles, but for cryptographic | timestamp field has played both these roles, but for cryptographic | |||
| purposes this is suboptimal because it is only 64 bits long and, | purposes this is suboptimal because it is only 64 bits long and, | |||
| depending on implementation details, most of those bits may be | depending on implementation details, most of those bits may be | |||
| predictable. In contrast, the Unique Identifier extension field | predictable. In contrast, the Unique Identifier extension field | |||
| enables a degree of unpredictability and collision resistance more | enables a degree of unpredictability and collision resistance more | |||
| consistent with cryptographic best practice. | consistent with cryptographic best practice. | |||
| skipping to change at page 24, line 28 ¶ | skipping to change at page 24, line 28 ¶ | |||
| Servers should select an AEAD algorithm which they will use to | Servers should select an AEAD algorithm which they will use to | |||
| encrypt and authenticate cookies. The chosen algorithm should be one | encrypt and authenticate cookies. The chosen algorithm should be one | |||
| such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidental | such as AEAD_AES_SIV_CMAC_256 [RFC5297] which resists accidental | |||
| nonce reuse. It need not be the same as the one that was negotiated | nonce reuse. It need not be the same as the one that was negotiated | |||
| with the client. Servers should randomly generate and store a secret | with the client. Servers should randomly generate and store a secret | |||
| master AEAD key `K`. Servers should additionally choose a non-secret, | master AEAD key `K`. Servers should additionally choose a non-secret, | |||
| unique value `I` as key-identifier for `K`. | unique value `I` as key-identifier for `K`. | |||
| Servers should periodically (e.g., once daily) generate a new pair | Servers should periodically (e.g., once daily) generate a new pair | |||
| (I,K) and immediately switch to using these values for all newly- | `(I,K)` and immediately switch to using these values for all newly- | |||
| generated cookies. Following each such key rotation, servers should | generated cookies. Following each such key rotation, servers should | |||
| securely erase any previously generated keys that should now be | securely erase any previously generated keys that should now be | |||
| expired. Servers should continue to accept any cookie generated | expired. Servers should continue to accept any cookie generated | |||
| using keys that they have not yet erased, even if those keys are no | using keys that they have not yet erased, even if those keys are no | |||
| longer current. Erasing old keys provides for forward secrecy, | longer current. Erasing old keys provides for forward secrecy, | |||
| limiting the scope of what old information can be stolen if a master | limiting the scope of what old information can be stolen if a master | |||
| key is somehow compromised. Holding on to a limited number of old | key is somehow compromised. Holding on to a limited number of old | |||
| keys allows clients to seamlessly transition from one generation to | keys allows clients to seamlessly transition from one generation to | |||
| the next without having to perform a new NTS-KE handshake. | the next without having to perform a new NTS-KE handshake. | |||
| End of changes. 14 change blocks. | ||||
| 37 lines changed or deleted | 41 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||