From d1e2dccc37300391a289307a1b4821c6cb22e2da Mon Sep 17 00:00:00 2001 From: Folkert Date: Wed, 20 Dec 2023 12:06:13 +0100 Subject: [PATCH 1/3] notes --- draft-venhoek-nts-pool.md | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/draft-venhoek-nts-pool.md b/draft-venhoek-nts-pool.md index efe2657..36e83d9 100644 --- a/draft-venhoek-nts-pool.md +++ b/draft-venhoek-nts-pool.md @@ -49,7 +49,7 @@ NTS {{RFC8915}} provides authenticity and limited confidentiality for NTP {{RFC5 This document aims to provide extensions to the NTS Key Exchange sessions that allow for an implementation of a pool for NTS that: - - Is usable without changes to client, + - is usable without changes to the client, - avoids constraining the downstream time source's cookie format, - avoids downstream time sources having potential access to all traffic. @@ -63,14 +63,14 @@ Where further specificity of the role of a participant is needed, we will use th # General pool architecture -We propose a pool model where the pool provides an NTS Key Exchange service to the outside world. This allows the pool to terminate the TLS connection and avoids having to distribute certificates to all downstream time servers. However, that also implies that the pool needs to extract the keys and get valid cookies for the selected downstream time server. +We propose a pool model where the pool provides an NTS Key Exchange service to the outside world. A major advantage of this model is that it avoids having to distribute certificates to all downstream time servers. -To solve this, we ask downstream servers to provide an extension of the NTS Key Exchange protocol that allows the pool to directly communicate the keys to the downstream server, instead of having the downstream server extract this from the TLS session. The explicit communication of keys allows the pool to do the extraction from the TLS server whilst remaining oblivious to the cookie format of the downstream server. +Contrary to {{RFC8915}}, there is no direct TLS connection between the client and the selected downstream time server. In {{RFC8915}}, cookies are generated based on key material that is extracted from this TLS connection. Our proposed model instead establishes two TLS connections: between the client and the pool, and between the pool and the downstream time server. Because cookies need to be generated using key material from the client, the pool extracts this key material and sends it to the server. The server uses this key material (rather than key material extracted from its connection with the pool) to generate cookies. The pool can remain oblivious to the cookie format of the downstream time server. # Client facilities for pools -One challenge with a pool through NTS Key Exchange is that clients that allow for explicit pool configuration want to end up with multiple independent time sources. To ensure they won't have to do multiple NTS Key Exchange sessions just to discard the result because they already have the time server they -result in, we also introduce a record clients can use to indicate which downstream time servers they don't want. +One challenge with a pool through ??? NTS Key Exchange is that clients that allow for explicit pool configuration want to end up with multiple independent time sources. To ensure they won't have to do multiple NTS Key Exchange sessions just to discard the result because they already have the time server they +result in, we also introduce a record that clients can use to indicate which downstream time servers they don't want. # New NTS record types @@ -80,11 +80,11 @@ Critical bit: 0 Indicates a desire to keep the TLS connection active for more than one message exchange. This can be used by a pool to reuse connections to downstream NTS Key Exchange servers multiple times, reducing load on both the pool and downstream servers. -Client MUST send this record with a 0 sized body. Client MUST NOT use Keep Alive unless the request contains a record type allowing the use of Keep Alive. Within this specification, that is limited to the Supported Protocol List and Fixed Key Request records. A server SHOULD ignore any body for the Keep Alive record. +Client MUST send this record with a body of size 0. Client MUST NOT use Keep Alive unless the request contains a record type allowing the use of Keep Alive. Within this specification, that is limited to the Supported Protocol List and Fixed Key Request records. A server SHOULD ignore any body for the Keep Alive record. -When supported by server and allowed for the request in question, the server MUST include a Keep Alive record with 0 sized body in the response and keep the TLS connection active after the response to handle further requests from the client. A client SHOULD ignore any body for the Keep Alive record. +When supported by server and allowed for the request in question, the server MUST include a Keep Alive record with a body of size 0 in the response and keep the TLS connection active after the response to handle further requests from the client. A client SHOULD ignore any body for the Keep Alive record. -When included in the request or response, the client respectively server MAY, contrary to the requirements in {{RFC8915}}, send another request or response. Any TLS "close_notify" SHALL be sent only after the last request or response respectively to use the connection. +When included in the request or response, the client respectively server MAY, contrary to the requirements in {{RFC8915}}, send another request or response. Any TLS "close_notify" SHALL be sent only after the last request or response respectively to ??? use the connection. Once a Keep Alive record has been sent by a client, or honored by a server, the TLS connection over which it was sent MUST NOT be used for key extraction. Doing so anyway can result in the reuse of keys and may result in loss of confidentiality or authenticity of the resulting NTP exchanges. @@ -94,9 +94,9 @@ Critical bit: 1 This record can be used by a pool to query downstream servers about which next protocols they support. -Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. A request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. +Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. A request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. (this is also in conflict with the NTS spec!) -Server MUST ignore any client body sent and MUST send in response a Supported Next Protocol List record with as data a list of 16 bit integers, giving the protocol IDs the server supports. +Server MUST ignore any client body sent and MUST send in response a Supported Next Protocol List record with as data a list of 16-bit integers, giving the protocol IDs the server supports. When included, the server MUST NOT negotiate a next protocol, AEAD algorithm, or keys for this request. @@ -106,9 +106,11 @@ Critical bit: 1 This record can be used by a pool to query downstream servers about which AEAD algorithms they support. -Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. A request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. +Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. A request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. (this is also in conflict with the NTS spec!) -Server MUST ignore any client body sent and MUST send in response a Supported Algorithm List record with as data a list of tuples of two 16 bit integers, the first giving an algorithm ID for the AEAD and the second giving the length of the key for that algorithm ID. +Server MUST ignore any client body sent and MUST send in response a Supported Algorithm List record with as data a list of tuples of two 16-bit integers, the first giving an algorithm ID for the AEAD and the second giving the length of the key for that algorithm ID. + +(maybe clarify why that key length is sent over the wire? I keep forgetting why that is useful) When included, the server MUST NOT negotiate a next protocol, AEAD algorithm, or keys for this request. @@ -116,7 +118,7 @@ When included, the server MUST NOT negotiate a next protocol, AEAD algorithm, or Record Type Number: To be assigned by IANA (draft implementations: 0x4002) Critical Bit: 1 -When client is properly authenticated, the server SHOULD NOT perform Key Extraction but rather use the keys provided by the client in the extension field. This allows a pool to do key negotiation on behalf of its users with the downstream NTS Key Exchange servers, even though it terminates the TLS connection. +When client is properly authenticated, the server SHOULD NOT perform Key Extraction but rather use the keys provided by the client in the extension field. This allows a pool to do key negotiation on behalf of its users with the downstream NTS Key Exchange servers, even though it terminates the TLS connection. (is "terminates" a technical term here? as in it is the opposite for "forwards" or something?) When used, the client MUST provide an AEAD Algorithm Negotiation record with precisely one algorithm, and a Next Protocol Negotiation record with precisely one next protocol. The data in the Fixed Key Request record must have length twice the key length N of the AEAD algorithm in the AEAD Algorithm Negotiation record. The first N bytes MUST be the C2S Key and the second set of N bytes MUST be the S2C key. Clients MAY use Keep Alive in combination with this record. @@ -136,15 +138,15 @@ MUST NOT be sent by a server. Server MAY at its discretion ignore the request fr ## Pool's position -In the pool design presented above, the pool effectively acts as a man in the middle between the user and the ultimate time source during the NTS Key Exchange portion of the session. This means that the pool has access to the key material of all these sessions. Although this is a small additional risk, we consider this acceptable as the pool could already always assign sessions for a user to time servers it controls anyway. +In the pool design presented above, the pool effectively acts as a man in the middle between the user and the ultimate time source during the NTS Key Exchange portion of the session. This means that the pool has access to the key material of both of these sessions. Although this is a small additional risk, we consider this acceptable because the pool could already always assign sessions for a user to time servers it controls anyway. -The fact that the pool also gets access to key material makes it less advisable to have a pool as a downstream time source for another pool, as this increases the number of actors with access to the key material even further. +The fact that the pool also gets access to key material makes it less advisable to have a pool as a downstream time source for another pool, because this increases the number of actors with access to the key material even further. The design above does avoid sharing key material between all downstream time sources. As a consequence, a downstream time source in the pool will not be able to break confidentiality or authenticity of traffic with other downstream time sources of the pool. Furthermore, any traffic directly with the downstream time source has no key material involved that is known to the pool. ## Error handling -To avoid giving multiple downstream time sources access to the key material of the end user, it is important that the keys extracted from the TLS session between the user and the pool are sent to at most one downstream time source. If an error occurs after sending the Fixed Key Request record, either with the TLS connection between the pool and the downstream time source, or by being explicitly reported by the downstream time source to the pool, the pool SHOULD return an error to the user. Retrying with a different downstream time source may unintentionally leave the user vulnerable to the provider of the originally selected downstream time source. +To avoid giving multiple downstream time sources access to the key material of the end user, it is important that the keys extracted from the TLS session between the user and the pool are sent to at most one downstream time source. If an error occurs after sending the Fixed Key Request record, either with the TLS connection between the pool and the downstream time source, or by being explicitly reported by the downstream time source to the pool, the pool SHOULD return an error to the user. Retrying with a different downstream time source may unintentionally leave the user vulnerable to the operator of the originally selected downstream time source. # IANA Considerations From 935e2242d5e86633c16761043291612087734e3e Mon Sep 17 00:00:00 2001 From: David Venhoek Date: Thu, 21 Dec 2023 08:56:53 +0100 Subject: [PATCH 2/3] Adapted folkerts suggestion for the document. --- draft-venhoek-nts-pool.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/draft-venhoek-nts-pool.md b/draft-venhoek-nts-pool.md index 36e83d9..4191a0d 100644 --- a/draft-venhoek-nts-pool.md +++ b/draft-venhoek-nts-pool.md @@ -63,14 +63,13 @@ Where further specificity of the role of a participant is needed, we will use th # General pool architecture -We propose a pool model where the pool provides an NTS Key Exchange service to the outside world. A major advantage of this model is that it avoids having to distribute certificates to all downstream time servers. +We propose a pool model where the pool provides an NTS Key Exchange service to the outside world. A major advantage of this model is that it avoids having to distribute certificates to all downstream time servers. Contrary to {{RFC8915}}, there is no direct TLS connection between the client and the selected downstream time service. -Contrary to {{RFC8915}}, there is no direct TLS connection between the client and the selected downstream time server. In {{RFC8915}}, cookies are generated based on key material that is extracted from this TLS connection. Our proposed model instead establishes two TLS connections: between the client and the pool, and between the pool and the downstream time server. Because cookies need to be generated using key material from the client, the pool extracts this key material and sends it to the server. The server uses this key material (rather than key material extracted from its connection with the pool) to generate cookies. The pool can remain oblivious to the cookie format of the downstream time server. +In {{RFC8915}}, cookies are generated based on key material that is extracted from this TLS connection. Our proposed model instead establishes two TLS connections: between the client and the pool, and between the pool and the downstream time server. Because cookies need to be generated using key material from the client, the pool extracts this key material and sends it to the server. The server uses this key material (rather than key material extracted from its connection with the pool) to generate cookies. This way, the pool can remain oblivious to the cookie format of the downstream time server. # Client facilities for pools -One challenge with a pool through ??? NTS Key Exchange is that clients that allow for explicit pool configuration want to end up with multiple independent time sources. To ensure they won't have to do multiple NTS Key Exchange sessions just to discard the result because they already have the time server they -result in, we also introduce a record that clients can use to indicate which downstream time servers they don't want. +One challenge with getting multiple time sources from a single NTS Key Exchange server is that clients that allow for explicit pool configuration want to end up with multiple independent time sources. Without additional support, a user of a pool might receive a downstream time source it already has from an NTS Key Exchange session, resulting in that session being a waste of time. To avoid this, we also introduce a record that clients can use to indicate which downstream time servers they don't want, because they already have them. # New NTS record types @@ -84,7 +83,7 @@ Client MUST send this record with a body of size 0. Client MUST NOT use Keep Ali When supported by server and allowed for the request in question, the server MUST include a Keep Alive record with a body of size 0 in the response and keep the TLS connection active after the response to handle further requests from the client. A client SHOULD ignore any body for the Keep Alive record. -When included in the request or response, the client respectively server MAY, contrary to the requirements in {{RFC8915}}, send another request or response. Any TLS "close_notify" SHALL be sent only after the last request or response respectively to ??? use the connection. +When included in the request or response, the client respectively server MAY, contrary to the requirements in {{RFC8915}}, send another request or response. Any TLS "close_notify" SHALL be sent only after the last request or response respectively to use the connection. Once a Keep Alive record has been sent by a client, or honored by a server, the TLS connection over which it was sent MUST NOT be used for key extraction. Doing so anyway can result in the reuse of keys and may result in loss of confidentiality or authenticity of the resulting NTP exchanges. @@ -94,7 +93,7 @@ Critical bit: 1 This record can be used by a pool to query downstream servers about which next protocols they support. -Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. A request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. (this is also in conflict with the NTS spec!) +Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. Contrary to {{RFC8915}}, a request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. Server MUST ignore any client body sent and MUST send in response a Supported Next Protocol List record with as data a list of 16-bit integers, giving the protocol IDs the server supports. @@ -106,19 +105,19 @@ Critical bit: 1 This record can be used by a pool to query downstream servers about which AEAD algorithms they support. -Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. A request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. (this is also in conflict with the NTS spec!) +Client MUST send with no body. Clients MAY use Keep Alive in combination with this record. Contrary to {{RFC8915}}, a request with this record SHOULD NOT include a "Next Protocol Negotiation", "AEAD Algorithm Negotiation" or "Fixed Key Request" record. Server MUST ignore any client body sent and MUST send in response a Supported Algorithm List record with as data a list of tuples of two 16-bit integers, the first giving an algorithm ID for the AEAD and the second giving the length of the key for that algorithm ID. -(maybe clarify why that key length is sent over the wire? I keep forgetting why that is useful) - When included, the server MUST NOT negotiate a next protocol, AEAD algorithm, or keys for this request. +We include algorithm key size in the response so that a pool does not itself need knowledge of which AEAD algorithm's exist, and what their key sizes are. Instead, it can use the provided key length when extracting keys from the TLS connection between end user and pool. This allows adoption of new AEAD algorithms without any software changes being needed in pool software. + ## Fixed Key Request {#fixedkey} Record Type Number: To be assigned by IANA (draft implementations: 0x4002) Critical Bit: 1 -When client is properly authenticated, the server SHOULD NOT perform Key Extraction but rather use the keys provided by the client in the extension field. This allows a pool to do key negotiation on behalf of its users with the downstream NTS Key Exchange servers, even though it terminates the TLS connection. (is "terminates" a technical term here? as in it is the opposite for "forwards" or something?) +When client is properly authenticated, the server SHOULD NOT perform Key Extraction but rather use the keys provided by the client in the extension field. This allows a pool to do key negotiation on behalf of its users with the downstream NTS Key Exchange servers, even though it terminates the TLS connection. When used, the client MUST provide an AEAD Algorithm Negotiation record with precisely one algorithm, and a Next Protocol Negotiation record with precisely one next protocol. The data in the Fixed Key Request record must have length twice the key length N of the AEAD algorithm in the AEAD Algorithm Negotiation record. The first N bytes MUST be the C2S Key and the second set of N bytes MUST be the S2C key. Clients MAY use Keep Alive in combination with this record. @@ -138,9 +137,9 @@ MUST NOT be sent by a server. Server MAY at its discretion ignore the request fr ## Pool's position -In the pool design presented above, the pool effectively acts as a man in the middle between the user and the ultimate time source during the NTS Key Exchange portion of the session. This means that the pool has access to the key material of both of these sessions. Although this is a small additional risk, we consider this acceptable because the pool could already always assign sessions for a user to time servers it controls anyway. +In the pool design presented above, the pool effectively acts as a man in the middle between the user and the ultimate time source during the NTS Key Exchange portion of the session. This means that the pool has access to the key material of these sessions. Although this is a small additional risk, we consider this acceptable because the pool could already always assign sessions for a user to time servers it controls anyway. -The fact that the pool also gets access to key material makes it less advisable to have a pool as a downstream time source for another pool, because this increases the number of actors with access to the key material even further. +The fact that the pool also gets access to key material makes it less advisable to have a pool as a downstream time source for another pool, as this increases the number of actors with access to the key material even further. The design above does avoid sharing key material between all downstream time sources. As a consequence, a downstream time source in the pool will not be able to break confidentiality or authenticity of traffic with other downstream time sources of the pool. Furthermore, any traffic directly with the downstream time source has no key material involved that is known to the pool. From 7d375f521c90e0abfd6226a345aa7c79f7c99b92 Mon Sep 17 00:00:00 2001 From: David Venhoek Date: Thu, 21 Dec 2023 08:58:50 +0100 Subject: [PATCH 3/3] Added folkert to author list. --- draft-venhoek-nts-pool.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-venhoek-nts-pool.md b/draft-venhoek-nts-pool.md index 4191a0d..663399b 100644 --- a/draft-venhoek-nts-pool.md +++ b/draft-venhoek-nts-pool.md @@ -27,6 +27,10 @@ author: fullname: "David Venhoek" organization: Tweede golf B.V. email: "david@tweedegolf.com" + - + fullname: "Folkert de Vries" + organization: Tweede golf B.V. + email: "folkert@tweedegolf.com" normative: RFC8915: