1:draft-nts: https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp 2= NTS support specification 3 4== Cisco's Statement of Work requirements 5 6The NTS implementation shall: 7 8* Use OpenSSL 1.1.1 for its crypto functions. 9 10* Address RFC5705 Keying Material Exporting and AES_SIV (RFC5297) code 11 support which may not be natively supported in OpenSSL. 12 13* Comply with the standardized specification of link:{draft-nts}[NTS] 14 15* Be interoperable with the other reference implementations in IETF hackathons. 16 17== General Ideas 18 19The NTP server maintains no per-client state. The necessary state 20is provided by a cookie that is included with each NTP request. An 21initial batch of cookies is provided by the NTS-KE server. The 22NTP client treats the cookies as opaque data and sends one to the 23NTP server with each request. 24 25A cookie contains the AEAD algorithm and keys necessary to 26authenticate a request. They are encrypted with the NTP servers 27key. The NTP server decrypts the cookie to retrieve the 28encryption parameters (AEAD algorithm and keys) and then uses 29them to authenticate the packet. To issue a new cookie, the NTP 30server makes a new nonce and uses the AEAD algorithm and keys 31from the old cookie. 32 33NTS should avoid exposing information that would be useful in 34tracking the client. (Consider a laptop that moves from home 35to work to a coffee shop.) Thus cookies should only be used once. 36To implement that, each NTP response includes a new cookie, which is 37encrypted when sent to the client. (Otherwise, the cookie could be 38observed in transit, which would allow for tracking the client when 39it later echoes that cookie back to the server.) 40 41NTS should not assist DDoS amplification. All NTP responses 42are the same length as the request. This means that some 43fields are padded to match the length of the response that 44will replace them. 45 46== System Partitioning 47 48This picture is for discussion. In actual packaging Alpha and Bravo 49will both be inside ntpd. In the simple case, Charlie and Delta can 50also be packaged together. In complicated cases, Delta could serve multiple 51Charlies, e.g. in a data-center deployment or for load sharing. 52 53image:NTS-flow.svg[] 54 55---- 56 ╔═══════════════════╗ 57 ║ Client ║ 58 ║ ┌───────────────┐ ║ ┌───────────────┐ 59 ║ │ Bravo │ ║ │ Delta │ 60 ║ │ NTS-KE client ├─╫──────────►│ NTS-KE server │◄─┐ 61 ║ └───────────────┘ ║ └─────┬─────────┘ │ 62 ║ ▲ ║ │ │ 63 ║ │ ║ │ ┌────┴───────┐ 64 ║ │ ║ │ │ Admin: Key │ 65 ║ │ ║ │ └────┬───────┘ 66 ║ │ ║ ▼ │ 67 ║ ┌───┴────────┐ ║ ┌─────────────┐ │ 68 ║ │ Alpha │ ║ │ Charlie │◄───┘ 69 ║ │ NTP client ├────╫──────────►│ NTP server │ 70 ║ └────────────┘ ║ └─────────────┘ 71 ╚═══════════════════╝ 72---- 73 74In this diagram, an arrow means "initiates requests to". 75Responses flow in the other direction. Each connection 76is used for one request/response transaction. 77 78 79The NTS-KE server has to make cookies that the NTP server 80will process. There are 2 ways to do that. First, they can share 81the same key, new-cookie recipe, and new-key recipe. If they are 82in separate systems, the admin must set up the initial key and keep 83the keys in sync if either system gets trashed. The second way is 84for the NTS-KE server to ask the NTP server for new cookies. If it 85does that, it doesn't need to know the key or anything about the 86contents of a cookie. 87 88 89=== Alpha -> Bravo 90NTP client to NTS-KE client (Alpha to Bravo) is pretty simple. 91As these will both be inside ntpd, this will be function calls, 92not a network connection. 93 94==== NTS-KE client sends: 95- Hostname of NTS-KE server 96- Optional preferred NTPD server hostname or IP Address 97 link:{draft-nts}#section-4.1.7[4.1.7] 98- A sorted list of AEAD algorithms link:{draft-nts}#section-4.1.5[4.1.5] 99 100==== NTS-KE server and NTS-KE client compute from the TLS connection: 101- C2S and S2C encryption keys link:{draft-nts}#section-4.2[4.2], 102 link:{draft-nts}#section-5.1[5.1] 103 104==== NTS-KE client gets back: 105- NTPD server hostname or IP Address link:{draft-nts}#section-4.1.7[4.1.7] 106- 1 to 8 cookies link:{draft-nts}#section-4.1.6[4.1.6] 107- The selected AEAD algorithm link:{draft-nts}#section-4.1.5[4.1.5] 108 109For AEAD, we need libaes_siv.so, RFC 5297 110It's not in OpenSSL yet. 111 https://github.com/dfoxfranke/libaes_siv 112 113An NTP client SHOULD NOT initiate NTS-KE by default. Configuration 114parameters from the NTPD config file will tell the NTPD client when and 115how to initiate NTS-KE. 116 117While it is technically permitted (see RFC5280, page 35) to put an IP 118address in a subjectAltName in a certificate, this is essentially never 119done in practice, and rarely with public CAs. Accordingly, the NTS-KE 120client SHOULD NOT generally initiate NTS for servers specified by IP 121address (whether IPv4 or IPv6). The NTS-KE client MAY initiate NTS 122for servers specified by IP address (whether IPv4 or IPv6) for testing 123purposes. 124 125Additionally, the NTP client SHOULD NOT initiate NTS for pool 126associations by default. The most common pool is the public pool at 127pool.ntp.org. The volunteer NTP servers will never be able to pass a 128certificate check for <anything>.pool.ntp.org, so NTS-KE will always 129fail, and represents a useless load on the public pool servers. As the 130pool statement can be used in other configurations that could work 131with NTS-KE, the NTP client SHOULD allow NTS to be enabled on pool 132associations. 133 134The NTS-KE client SHOULD provide a configuration parameter to 135configure the root CAs used to validate TLS certificates. 136 137The NTS-KE client SHOULD have a configuration parameter to specify 138which TLS protocols are permissible. Regardless of what is 139configured, because the NTS specification relies on RFC 5705, and 140also because it explicitly says so, TLS 1.3 is the minimum TLS 141version allowed. 142 143The NTS-KE client SHOULD provide a configuration parameter to 144configure an OpenSSL cipher string for the TLS connection. 145 146The NTS-KE client SHOULD provide a configuration parameter to 147configure an OpenSSL cipher string for the AEAD algorithms. 148 149The NTP client SHOULD provide a mechanism for the administrator to 150see whether NTS is currently in use on a given server association. 151 152=== Bravo -> Delta 153The NTS-KE client to NTS-KE server (Bravo to Delta) communication is 154mostly the above in TLS 1.3 (or later) over TCP in the format 155specified in the NTS draft. 156 157The NTS-KE client (Bravo) and NTS-KE server (Delta) independently 158derive the C2S and S2C keys. For OpenSSL, this is implemented by 159making two calls to SSL_export_keying_material(), which implements 160RFC5705. The label and context inputs are provided in 161link:{draft-nts}#section-5.1[5.1]. 162This process is deterministic, so both ends generate the same C2S and S2C. 163 164The NTS-KE client passes C2S and S2C to the NTP client. The NTS-KE 165server uses them to make the initial cookies. 166 167The NTS-KE server then generates and returns 8 cookies using, for 168example, the suggested format in section 6 of the NTS draft. To do 169so, the NTS-KE server needs a master key, called "K" in the draft. 170 171=== Alpha -> Charlie 172NTP client to NTP server (Alpha to Charlie) 173 174If all goes well (no lost packets) the client sends: 175 176- The normal 48 byte NTP packet 177- A 32+ byte unique ID link:{draft-nts}#section-5.3[5.3] 178- A cookie link:{draft-nts}#section-5.4[5.4] 179- Authentication using C2S link:{draft-nts}#section-5.6[5.6] 180 181It gets back the same, with the cookie replaced with a new cookie 182and S2C used for authentication and to encrypt the new cookie. 183 184The response is the same length. 185 186All the extra data is in real NTP extensions. (No more of 187the magic length kludgery for the current shared key authentication.) 188 189If packets (and hence cookies) are lost, the client will include 190a cookie-placeholder for each extra cookie it wants. 191link:{draft-nts}#section-5.5[5.5] 192Those slots will be returned with new cookies. 193 194The AEAD algorithm used for authentication is set up to encrypt some 195data as well. For the request, the encrypted data is empty. For the 196response, it contains a new cookie (or cookies). AEAD also needs a nonce; 197see below for discussion and security concerns. 198 199== Configuration 200 201The NTS-KE server SHOULD have a configuration parameter to specify 202which TLS protocols are permissible. Regardless of what is 203configured, because the NTS specification relies on RFC 5705, and 204also because it explicitly says so, TLS 1.3 is the minimum TLS 205version allowed. 206 207The NTS-KE server SHOULD have a configuration parameter to specify its 208preferred AEAD algorithms for the TLS connection in preference order. 209This SHOULD be provided as an OpenSSL cipher string. 210 211The NTS-KE server SHOULD have a configuration parameter to specify 212its preferred AEAD algorithms for the NTPD connection in preference 213order. This SHOULD be provided as an OpenSSL cipher string. 214AEAD_AES_SIV_CMAC_256 [RFC5297] MUST be supported[4.1.5]. 215 216The nonce situation has impacts on algorithm choice. There are two ways 217to generate a nonce: randomly or as a counter. Given the hard 218requirement that the server be stateless, the only place for the server 219to store state is in the cookie. Clients are allowed to reuse cookies, 220so the server cannot use the cookie to store nonce state. No matter what 221state the server stores in the cookie, if the client replays a cookie, 222the server would replay the nonce. 223 224Unless the AEAD algorithm is specifically designed to be nonce-misuse 225resistant, then reusing the nonce catastrophically breaks the security. 226For example, the AES-GCM RFC [RFC5116] says, " 227 The inadvertent reuse of the same nonce by two invocations of the GCM 228 encryption operation, with the same key, but with distinct plaintext 229 values, undermines the confidentiality of the plaintexts protected in 230 those two invocations, and undermines all of the authenticity and 231 integrity protection provided by that key. For this reason, GCM 232 should only be used whenever nonce uniqueness can be provided with 233 assurance." 234 235So we might as well generate the nonce randomly rather than jumping 236through hoops to try to implement a counter-based nonce that will fail 237anyway under cookie reuse. A random nonce also prevents the client from 238gaining some advantage by reusing the cookie maliciously. But a 239randomly-generated nonce also does not _guarantee_ that nonce reuse will 240not happen. Thus, absent contrary guidance from a cryptography expert, 241the AEAD algorithm MUST be nonce-misuse resistant. The only current AEAD 242algorithms with this property are AEAD_AES_SIV_CMAC in 256, 384, and 512 243variants and AEAD_AES_128_GCM_SIV in 128 and 256 variants. This can be 244verified by checking each AEAD algorithm's specification. 245 246Honoring the NTS-KE client's AEAD preference order for the NTPD 247connection is OPTIONAL[4.1.5]. The typical approach is to honor the 248client's order by default (i.e. pick the first algorithm in the client's 249list which is supported by the server), unless a configuration option has 250been set on the server to reverse that (i.e. pick the first algorithm in 251the server's list which is supported by the client). 252 253The NTS-KE server SHOULD have a configuration parameter to specify 254the TLS key, certificate, and intermediate certificate bundles. 255 256The NTS-KE server MAY have a method to reload the key, certificate, 257and intermediate certificate bundles without a full daemon restart. 258 259== NTS Configuration parameters (client side) 260 261Options now implemented in the config parser are now described in 262docs/includes/auth-commands.txt 263 264To avoid having to hand-configure TLS versions, the right (and 265conformant) thing is to do is honor the global mintls and maxtls 266options, then just use the most recent version at or above it your TLS 267library and the remote both support. If the remote can't cope, you 268abort. 269 270To avoid having to hand-configure ciphers offered to the remote, we 271can initially have a list of common known-good ones wired in. Eventually, 272this list should be configurable. For the reasons discussed above in the 273server section, the client's default list of ciphers SHOULD be restricted 274to only those algorithms known to be nonce-misuse resistant. 275 276== NTS-KE Server Configuration parameters 277 278== TLS Options 279 280The directory with the Certificates of Certification Authorities (CAs). 281 282.... 283TLSCACertificatePath directory-path 284.... 285 286A file with this NTS-KE servers certificate data in PEM format. May 287include chain certificates. 288 289.... 290TLSCertificateFile file-path 291.... 292 293The PEM-encoded private key file for the server. 294 295.... 296TLSCertificateKeyFile file-path 297.... 298 299A colon-separated cipher-spec string consisting of OpenSSL cipher 300specifications to configure the Cipher Suite the client is permitted 301to negotiate in the TLS handshake phase. 302 303.... 304TLSCipherSuite TLS1.3 cipher-spec 305.... 306 307A colon-separated cipher-spec string consisting of OpenSSL AEAD cipher 308specifications to configure the cipher suite for the NTP traffic. 309 310Therefore, the server MUST restrict the list of AEAD algorithms to only 311those algorithms known to be nonce-misuse resistant. 312 313For the reasons discussed above, the server MUST limit the accepted AEAD 314algorithms in this to only those algorithms known to be nonce-misuse 315resistant. Maybe this should be downgraded to a SHOULD, because a new 316nonce-misuse resistant algorithm could be added to OpenSSL and ntpd would 317not know about it. If it is possible to just pass a cipher string to 318OpenSSL and let it filter the list of AEAD algorithms (as is possible with 319TLS), that makes sense. But if the NTS-KE server implementation has to 320parse this list itself and switch-case on the value, then it would have to 321be updated for new algorithms anyway, and it makes sense to leave this at 322a MUST. 323 324If no list is specified, the default list MUST include 325AEAD_AES_SIV_CMAC_256. However, if the user specifies a list, the server 326MUST NOT add AEAD_AES_SIV_CMAC_256 to that list implicitly, as this would 327preclude the user from disabling AEAD_AES_SIV_CMAC_256 in the future, 328should that become necessary. 329 330.... 331NTPCipherSuite cipher-spec 332.... 333 334Option to prefer the server's cipher preference order for the TLS connection. 335Default on. 336 337.... 338TLSHonorCipherOrder on|off 339.... 340 341Option to prefer the server's cipher preference order for the NTP packets. 342Default on. 343 344.... 345NTPHonorCipherOrder on|off 346.... 347 348Which versions of the TLS protocol will be accepted in new TLS connections. 349 350.... 351TLSProtocol [+TLS1.3] 352.... 353 354Configures one or more sources for seeding the Pseudo Random Number 355Generator (PRNG) in OpenSSL at startup time. One source per directive. 356Multiple directives may be used. Source may be: builtin, "file:/dev/random", 357"file:/dev/urandom", etc. 358 359.... 360TLSRandomSeed source [bytes] 361.... 362 363Sets the Certificate verification level for the Client Authentication. 364The level may be: none: no client Certificate is required at all, optional: 365the client may present a valid Certificate, require: the client has to 366present a valid Certificate, optional_no_ca: the client may present a 367valid Certificate but it need not be verifiable. 368 369.... 370TLSVerifyClient level 371.... 372 373 374== Key Generation and Usage 375 376NTS makes use of three keys: 377 378* Client to Server key (C2S) 379 380* Server to Client key (S2C) 381 382* NTS Master Key (called K in the NTS draft) 383 384Because one of the goals of NTS is to not require any per-client 385state in the servers, the servers (both NTP and NTS-KE) do not 386store either of C2S/S2C. Both servers possess the NTS Master Key, 387which is expected to be updated somewhat regularly, with old versions 388being kept for some time (SHOULD be two rotation cycles) to allow for 389old cookies to be decrypted. 390 391The C2S and S2C keys are derived from the TLS session data between 392the NTS-KE client and the NTS-KE server using the RFC5705 algorithm. 393These are not the same as the keys used by TLS to protect the data 394flowing over the TLS connection itself. 395 396As part of the setup, NTS-KE will create a variable number of cookies 397(which SHOULD be 8). These cookies are encrypted with the NTS Master 398Key, and are opaque to the client. The cookies contain C2S and S2C in 399a form that the NTP server will understand, and this is how the NTP 400server is able to en/decrypt data without needing to store per-client 401keys. 402 403When sending an NTP packet, the client attaches a cookie blob in 404cleartext, then authenticates the packet using the C2S key. When 405the NTP server receives the packet, it decrypts the cookie using its 406NTS Master Key to recover C2S and S2C. It uses C2S to authenticate the 407packet. For the response, S2C is used to encrypt the new cookies and 408authenticate the return packet. 409 410== Certificate Verification 411 412To recap: In normal operation, the client MUST verify the NTS-KE 413server's TLS certificate in the usual way, checking the certificate 414chain and the hostname. For testing or workaround purposes, a 415`noval` or similar configuration option SHOULD be provided which 416skips certificate validation. 417 418It is desirable to include a middle-ground option, where the 419certificate chain is validated, but certificate timestamps (`notBefore` 420and `notAfter`) are ignored. This would be useful to allow the client to 421correct for a bogus system clock. A specific subset of bogus system 422clock scenarios is that the system lacks an RTC, or the RTC's battery 423has died. However, such a mode should be carefully constructed to 424minimize the loss of security. If such a mode is implemented, the client 425MUST have a configuration option to enable/disable it. 426 427One possible implementation is as follows. 428 429If certificate validation is disabled entirely with the `noval` option, 430pass `SSL_VERIFY_NONE` to `SSL_CTX_set_verify()` and do not register any 431custom verification hook. These peers will be treated as if certificate 432verification succeeded, without any of the special "suspect" behavior 433or `notBefore`/`notAfter` checks. 434 435If the configuration option is set to strict security or if ntpd has 436already set the system clock, let OpenSSL handle certificate verification 437normally. That is, do not register a custom verification callback. This 438way, the risk of any bugs in the custom certificate verification code is 439contained to initial startup. Otherwise, register a custom callback 440with `SSL_CTX_set_cert_verify_callback()`, passing some state (e.g. a 441`peer` object) as the `arg` parameter. When the callback is called, 442perform certificate verification (leveraging built-in OpenSSL 443functionality to the extent possible!). If the verification fails for a 444reason other than certificate validity times, return failure. If a 445verification step fails due to certificate validity times, set a 446`peer->suspect` flag, but otherwise continue. 447 448As each certificate in the chain is inspected, save the _latest_ 449`notBefore` and _earliest_ `notAfter` into the peer object. In other 450words, if no value is saved (i.e. this is the first certificate), save 451the certificate's values; otherwise save the certificate's `notBefore` 452only if it is later than the existing `peer->notBefore` and save the 453certificate's `notAfter` only if it is earlier than the existing 454`peer->notAfter`. If an OCSP stapled response is present, similarly 455limit the peer's `notBefore` and `notAfter` values to the validity range 456of the OCSP stapled response. 457 458The objective of this is to limit the possible forged times that the 459client will accept. If the client is configured to require multiple 460sources of time (e.g. `minsane 3`), an attacker trying to re-use 461compromised expired certificates would need multiple such certificates 462with overlapping validity, and would still only be able to get the 463client to accept times within that period of overlap. This helps limit 464attacks. If a certificate uses OCSP "must staple", the attacker needs to 465replay OCSP responses too, which have much shorter validity periods (e.g. 4667 days), significantly limiting this even further. 467 468In the clock selection algorithm, very early on, add something like: 469 470---- 471if (peer->suspect) { 472 /* Suspect peers are ignored ("leave the island"), unless 473 * <some condition>. 474 */ 475 476 // <some condition> is something that indicates we would have 477 // "normally" synced the clock by now. My example was that 478 // reach (as output by ntpq -p) was 377 (i.e. we had 8 successful 479 // polls on that peer), or maybe allow for one missed? It probably 480 // cannot be time passed because the network could be down for an 481 // indeterminate length of time when ntpd comes up. 482 483 if (!<some condition>) 484 continue; 485} 486---- 487 488The idea here is that we spin up the suspect associations normally, but 489we ignore them for "a while" which would normally be sufficient to set 490the clock. If there are enough other associations working, great, we 491didn't use the suspect association(s) at all, so there was no loss in 492security. Only if we couldn't set the clock in a reasonable amount of 493time or whatever would we then fall back to considering the suspect 494associations. But, because they have been running the whole time rather 495than just starting now, we minimize the time to clock update when we do 496need to use the suspect associations. 497 498Once the clock is set the first time, kill all suspect associations 499(including those used to set the time), forcing those peers to re-run 500NTS-KE and start over. They will either pass normally or fail normally. 501Since the clock has now been set, only normal certificate validation will 502be allowed moving forward. 503 504Additionally, if the NTP server gives (authenticated) time earlier than 505the `peer->notBefore` value (if set), discard that time or mark the peer 506as a falseticker. If the server gives valid time, set a flag in the peer 507indicating that. If the server gives time after the `notAfter` and the 508peer's valid time flag is unset (the server has never given valid time), 509discard that time or mark the peer as a falseticker. These checks should 510never trigger on legitimate traffic, as that would mean the NTP server 511disagrees with its NTS-KE server's CA about time. 512link:{draft-nts}#section-9.3[9.3] 513 514It might be considered useful to always apply these 515`notBefore`/`notAfter` sanity checks, not just for "suspect" 516associations. If that is the case, then the `peer->notBefore` and 517`peer->notAfter` values will have to be set in all cases. However, in 518that event, it is still probably desirable to skip the custom certificate 519verification code, so determining the `notBefore` and `notAfter` values 520should be moved from the custom certificate verification callback to 521happen after certificate validation. 522 523== Odds and ends 524 525How many cookies should the NTP client try to hold? 8 526 527There is no hard reason, but it is what the NTS-KE server SHOULD return. 528link:{draft-nts}#section-4.1.6[4.1.6] 529It also matches the number of samples that ntpd remembers (the reach bit 530mask in ntpq/peers) and running out of responses is a good time to do 531special things like getting a new pool server or getting new cookies by running 532NTS-KE again. 533 534--- 535 536We need an exponential backoff when the NTS-KE step fails. 537 538--- 539 540Note that the communication between NTS-KE client and NTP client 541needs to be kept private. (aka encrypted if it goes over the net) 542Same for NTS-KE server and NTP server. 543Both connections contain C2S and S2C keys. 544 545--- 546 547Some interesting notes on OCSP stapling: 548https://blog.cloudflare.com/high-reliability-ocsp-stapling/ 549 550Also, here are some notes about how to implement good OCSP stapling on 551the server side: 552https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 553linked from: 554https://community.letsencrypt.org/t/ocsp-stapling-advantages-and-disadvantages/34465/11 555 556== Potential cookie recipe(s) 557 558. Form a plaintext "P" comprised of records 559.. minimum of an AEAD algorithm record, c2s, and s2c key records 560.. (optional) previously connected network address (for academic purposes) 561.. (optional) a timestamp when to stop honoring the current cookie series 562.. (optional) a timestamp when the current cookie series began (for expiration) 563.. (optional) a Modified Julian Date when to stop honoring the current cookie series 564.. (optional) a MJD when the current cookie series began (for expiration) 565.. (optional) a number of cookies remaining before series expiration. 566.. (optional) the number of cookies (estimated) since series began for expiration. 567. encrypt it with the master key "K" (which has nothing to do w/ TLS) 568. form the cookie w/ records for the master key number "I", an unsized nonce "N", and the ciphertext "C". 569 570---- 571base 29 NThkZGExNTYxZGY3YWQzMTkxOGI4OTQ0ZWQ5YTU3MTc= ZGZmZTg0MTBhZjk2YTgxOGE2ZDMwOGQ0Nzg0ZGMxNzg 572track 192.168.1.107 573btai 3753708891 574etai 3761747291 575bmjd 58460 576emjd 58557 577cdown 3460 578cup 4210 579---- 580 581An overly complicated example plaintext. records are carriage return terminated and fields are horizontal tab separated. 582The example is set in January of 2019 for a chain starting mid-December and ending mid-March. 583It is likely that only one of the expiry fields is desirable. 584The cookie count up/down counter should change by the number of cookies issued (8). 585The c2s/s2c fields should be base64 encoded. 586 587---- 58827391 MjI4MGVlYWY2ZWMzOGZjNmQ4MmFjMjhmMGViYzYxZTQ= U2FsdGVkX1/dO8WX4e+daOzR2dcRvbHOUv3jAMT51NttWrK+CnBUDWuhm54Hz31TG1P+VkWlrMGHAIHea9gQ3+shZj+I8pdPLrEn9V/E+1VJMC96qBo+x55yQmOyRLEJJSJMs25dSQ0idndKAOYqUOyulwruTe7QuPr+L5fVB9qSw2n18w/6BtnXsivAEjMpfxP9X7ZDZ46LHm1ayAcmMoccdjuwKqgPaa2ez33rlruXmcsF5omlguBZWxjm/iNZ 589---- 590 591A wholly made up example cookie. 592 593== Unresolved issues for the next RFC WG 594 595The binary KE request-response format is unfortunate for all the usual 596reasons (endianness issues etc). At the expected transaction volume, 597the encode/decode overhead shouldn't be an issue. 598 599How to make NTS-KE work, securely, with pooled servers? 600 601link:{draft-nts}#section-4.1.3[4.1.3], link:{draft-nts}#section-4.1.4[4.1.4] 602 603Is the response in case of abuse 'continue the abuse, just wait a minute'? 604 605link:{draft-nts}#section-5.7[5.7] 606 607Does the unique identifier extension need to be omniversally unique? 608 609Why are the timestamps, unique identifier extension etc. seemingly not tamper resisted? 610 611Can NTSN and other KODs get signed? 612 613== NTS/mode 7 next 614 615=== NTS and mode 6 and 7 616 617Network Time Security explicitly only supports modes 3 and 4 at this time. 618I see no reason why NTS could not be expanded to cover modes 1, 2, 6, and 7. 619Expansion to cover modes 6&7 should require an authentication token extension. 620 621More discussion of how to re-do Mode 6 has been moved to ntpv5.adoc. 622 623// end 624
