Switch from TLS to shared secret authentication.

Also includes some minor textual streamlining.

Author: davidv1992

draft-venhoek-nts-pool.md

@@ -82,15 +82,15 @@ To facilitate communication between the pool and the time sources, 4 new NTS rec
 
 The Supported Next Protocol List ({{supportedprotocol}}), Supported Algorithm List ({{supportedalgorithm}}) and List Server Names ({{listservernames}})) records allow the pool to ask a time source which protocols and algorithms it supports, and which server names are used in the NTP server records it generates. This information can be requested by the pool at any time, and can be cached for short periods of time to improve efficiency.
 
-Using knowledge of a time source's supported protocols and algorithms, the pool can then handle client connections for that time source, using the clients indicated desires to choose a concrete next protocol and AEAD algorithm. The pool can then extract the keys from the TLS connection and use the Fixed Key record ({{fixedkey}}) to request cookies for these keys from the time source.
+Using knowledge of a time source's supported protocols and algorithms, the pool can then handle client connections for that time source, using the clients indicated desires to choose a concrete next protocol and AEAD algorithm. The pool can then extract the keys from the TLS connection and use the Fixed Key record ({{fixedkey}}) to request cookies for these keys from the time source. The response to a request containing a Fixed Key record will be the same as that for any regular NTS Key Exchange response, with the exception that the keys will be taken from the Fixed Key record instead of being derived from the TLS connection.
 
 The list of server names provided by the time source can be used by the pool to honor requests by the client to not repeat a certain server. This allows more efficient retrieval of multiple sources from a pool.
 
 As it is wasteful to setup a new TLS session between the pool and the time source for each of these interactions. To facilitate reuse of the TLS sessions, we further introduce the Keep Alive record ({{keepalive}}). This record allows the pool to indicate to the time source a desire to keep the session alive for more than a single request-response interaction.
 
 ## Authenticating the pool to time sources {#poolauth}
 
-Allowing arbitrary clients to keep connections alive for more that a single request-response interaction could open up the server to denial of service due to resource exhaustion. To prevent this, a pool wishing to use the keep alive functionality MUST authenticate itself to the time source using a TLS Client Authentication as defined in {{RFC8446}}. Time sources MUST check that this authentication was successful, and that the requestor is on the list of requestors allowed to use the keep alive mechanism. By default, the list of requestors allowed to use the keep alive mechanism MUST be empty
+Allowing arbitrary clients to keep connections alive for more that a single request-response interaction could open up the server to denial of service due to resource exhaustion. To prevent this, a pool wishing to use the keep alive functionality MUST authenticate itself to the time source using an Authentication record ({{authentication}}). Time sources MUST check that the content of the authentication record matches the authentication string of a client that is on the list of requestors allowed to use the keep alive mechanism. By default, the list of requestors allowed to use the keep alive mechanism MUST be empty
 
 Furthermore, time sources MAY choose to also restrict the Fixed Key, Supported Next Protocol List and Supported Algorithm List to authenticated clients. If this choice is made, it is suggested that the server treat these records as unrecognized critical records on unauthenticated client's connections.
 
@@ -150,15 +150,15 @@ This record can be used by a pool to query time sources about which server names
 
 When a client sends this record the body MUST have size 0. 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.
 
-Servers MUST NOT include this record in a response. When receiving this record, servers MUST ignore any body of this record sent by the client, and MUST send in the response one NTP server record for each server name the server may use responses to fixed key requests. If a server never sents a NTP server record in response to a fixed key request, it MAY opt to not provide one in response to this record.
+Servers MUST NOT include this record in a response. When receiving this record, servers MUST ignore any body of this record sent by the client, and MUST send in the response one NTP server record for each server name the server may use responses to fixed key requests. If a server never sends a NTP server record in response to a fixed key request, it MAY opt to not provide one in response to this record.
 
 When receiving this record, a server MUST NOT negotiate a next protocol, AEAD algorithm, or keys for this request. A server MAY treat this record as unknown for clients that are not authenticated as described in {{poolauth}}.
 
 ## Fixed Key Request {#fixedkey}
 Record Type Number: To be assigned by IANA (draft implementations: 0x4002)
 Critical Bit: 1
 
-When a 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 time source's NTS Key Exchange servers, even though it terminates the TLS connection.
+When a client is properly authenticated, the server SHOULD NOT perform Key Extraction but rather use the keys provided by the client in the extension field. In all other aspects, the response SHALL be the same as that from a regular key exchange session as specified in {{RFC8915}}. This allows a pool to do key negotiation on behalf of its users with the time source's 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.
 
@@ -174,6 +174,16 @@ A client MAY send multiple of these records if desired. The data in the record S
 
 MUST NOT be sent by a server. Server MAY at its discretion ignore the request from the client and still provide the given server in an NTPv4 Server Negotiation record.
 
+## Authentication {#authentication}
+Record Type Number: To be assigned by IANA (draft implementations: 0x4005)
+Critical Bit: 0
+
+When provided by a client, gives a proof of their identity through a pre-shared secret token. This can be used to allow only certain clients, for example pools, to use certain functionality of an NTS key exchange server. In particular, it can be used to prevent misuse of the keep alive mechanism by clients other than the pool, preventing resource exhaustion denial of service attack.
+
+A client MUST send at most one of these records. The data in the record should be an ASCII string, previously agreed through an out of scope mechanism.
+
+MUST NOT be sent by a server. A server MAY use the record to gate acceptance of other records such as the Keep Alive, Fixed Key Request, List Server Names, Supported Algorithm List and Supported Next Protocol List records.
+
 # Security Considerations
 
 ## Pool's position